Джон Джестон, Йохан Нелис Управление бизнес-процессами.

Практическое руко-
водство по успешной реализации проектов. Пер. с англ.: Альпина Паблишер; Москва; 2012
ISBN 978-5-9614-3755-3

Аннотация
В предлагаемой книге подробно излагаются:
1. основополагающие принципы управления бизнес-процессами,
2. их преимущества и выгоды для организаций, а также приводятся
3. примеры осуществления такого управления.
В ней рассматривается:
1. общая схема,
2. комплекс инструментов и методов ВРМ, а также
3. выбор одного из четырех вероятных сценариев его реализации.
Книга содержит более пятидесяти конкретных примеров, иллюстрирующих различные
ее положения, а также этапы проекта ВРМ и основные атрибуты, которые являются важны-
ми факторами обеспечения успеха проекта. Вы:
 сможете заглянуть внутрь механизма, при помощи которого можно определить
готовность организации или структурного подразделения к ВРМ,
 поймете что, зачем и как делается при реальном усовершенствовании процессов.
Книга может служить справочником для организаций, осуществляющих проекты управ-
ления бизнес-процессами, поскольку материал, изложенный в ней, дает в руки группы про-
екта практический инструментарий, пояснения и помощь в успешной реализации проекта
ВРМ.
Переводчик В. Агапов
Научный редактор В. Тренев
Редактор Е. Бекназарова
Руководитель проекта А. Половникова
Корректор Е. Тульсанова
Компьютерная верстка М. Поташкин
Художник С. Прокофьева
Все права защищены. Никакая часть электронного экземпляра этой книги не может
быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами,
включая размещение в сети Интернет и в корпоративных сетях, для частного и публичного
использования без письменного разрешения владельца авторских прав.
© John Jeston and Johan Nelis, 2006
Published by Elsevier Ltd. All rights reserved.
© Издательство Символ-Плюс, 2008
© ООО «Альпина Паблишер», 2012
Нашим семьям.
Ивонне, Британни, Коннору, Кэсси и Курту.
Сандре, Анжелике и Мистик.
Без их поддержки мы бы не справились.
Мы знаем, что временами было очень трудно, и никогда не забудем ваше участие. Спа-
сибо вам!
Мы постараемся наверстать упущенное время для общения с вами.
Джон и Йохан
 Содержание
Об авторах и соавторах 5
Предисловие 7
Краткая история BPM 8
Чему учит история 10
Предыстория 12
Введение 13
Что есть продуктивность, или постоянное совершенствование бизнеса 14
Благодарности 16
Часть I 17
Глава 1 18
Краткая история управления бизнес-процессами 18
Очередная «гранд-идея», или как рождаются мифы 18
Цикл «раскрутки» BPM 19
Что загадочного в BPM 20
Синдром «вершины айсберга» 21
Исследуя «реальность» 22
Управление изменениями и измерение 22
производительности
Заключение 23
Глава 2 24
Глава 3 27
В чем проблема 27
Почему же это не работает 27
Почему автоматизация не дает ожидаемого результата 28
Чему учит история 29
Заключение 30
Глава 4 31
Глава 5 37
Управление бизнес-процессами 37
Управление бизнес-процессами как составная часть «управления» 38
Управление совершенствованием бизнес-процессов 38
Ближе к бизнесу 39
Привлечение внешних специалистов по BPM 39
Глава 6 41
Стратегия организации 41
Почему стратегия организации важна для бизнес-процессов 41
Что должна содержать стратегия организации и архитектура процессов, что-
бы создать подходящие условия для анализа и совершенствования процессов 42
Архитектура процессов 42

Об авторах и соавторах
Джон Джестон (John Jeston) работает в бизнесе и отраслях ИТ более тридцати лет,
управляя проектами и бизнес-процессами, занимаясь реинжинирингом бизнес-процессов,
разработкой систем, аутсорсингом, консультированием и общим управлением. Помимо сво-
ей занятости в консалтинге, он занимал должности финансового контролера, менеджера от-
деления, директора компании ПО, а также директора по ИТ.
Недавно Дж. Джестон стал специализироваться в стратегии и внедрении управления
бизнес-процессами и теперь является ведущим консультантом в практическом внедрении
BPM компании TouchPoint. Его сегодняшняя работа заключается в стратегическом консуль-
тировании в области BPM, большей частью в финансовой сфере, и управлении консультан-
тами фирмы TouchPoint при реализации различных проектов BPM. В последние три года он
проводил семинары на нескольких конференциях по BPM. Дж. Джестон является автором
руководителем курса обучения программы дистанционного обучения BPM в Австралии
(johnjeston@managementbyprocess.com).
Йохан Нелис (Johan Nelis) получил международный опыт как консультант-практик
управления бизнес-процессами. Он организовал и управлял работой в области BPM тридца-
ти консультантов в Голландии, а в настоящее время является соучредителем и вице-
председателем голландского Форума BPM. Нелис работал в качестве советника в ООН. Он
также хорошо известен своей тягой к передаче знаний и опыта и доказал способность стиму-
лировать и мотивировать людей. Он организовал много курсов обучения BPM и выступал с
лекциями для аспирантов.
Нелис работал во многих отраслях, с особым упором на финансы и связь, специализиро-
вался на согласовании и увязке процессов со стратегией, целями бизнеса и ИТ. Он провел
множество аудитов процессов и способен точно указывать жизнеспособные решения. Более
того, Нелис очень хорошо владеет инициированием и надзором за внедрением BPM и удачно
обеспечивает самостоятельное и улучшенное выполнение людьми своих функций. Сейчас он
работает ведущим консультантом в компании TouchPoint, где является советником по стра-
тегическим вопросам бизнес-процессов и руководит группой консультантов по BPM. Он вы-
ступал на семинарах и проводил практические занятия на нескольких конференциях по BPM
в Европе и Австралии. Нелис является автором и руководителем курса обучения программы
дистанционного обучения BPM в Голландии и Австралии
(johannellis@managementbyprocess.com).
Фриц Буссемейкер (Frits Bussemaker) работает в отрасли ИТ с 1988 года. Он занимал
различные руководящие коммерческие должности в компаниях, среди которых Logica
Cambridge Technology Partners. В настоящее время Буссемейкер является менеджером стра-
тегических альянсов компании TIBCO Software в Голландии. В 1999 году он организовал и
стал председателем голландского отделения Ассоциации профессионалов стратегических
альянсов (www.strategic-alliances.org). Буссемейкер также является учредителем председате-
лем Форума BPM в Голландии (www.bpm-forum.org), созданного в 2003 году, членом Коми-
тета советников Форума BPM в Бельгии, автором Business Process Management Magazine и
сайта bptrends.com. Получил степень магистра в Университете Делфта.
Тоня де Бруин (Tonia de Bruin) работает над кандидатской диссертацией в Технологи-
ческом университете Квинсленда в Австралии, где специализируется в области комплексно-
сти управления бизнес-процессами. Имея звание сертифицированного бухгалтера с 2001 го-
да, в 2004 году она получила звание магистра ИТ в том же университете. У нее большой
опыт работы в финансовой сфере, где в течение 15 лет она была и менеджером, и консуль-
тантом. Опыт управления в проектах совершенствования процессов вызвал у Тони острый
интерес к взаимосвязи между бизнес-процессами и ИТ.
Бред Пауэр (Brad Power) является исполнительным директором Исследовательского
центра бизнес-процессов в Бэбсон-колледже. Имея более чем двадцатилетний опыт консуль-
тирования в управлении и исследовательской работы в различных отраслях по всему миру,
он занимается важными вопросами бизнес-возможностей и проблемами клиентов, сочетая
человеческие, технологические и бизнес-аспекты. С 1981 по 1997 он работал в CSC Index,
фирме реинжиниринга. Возглавляя многие консалтинговые проекта инноваций процессов,
он в течение трех лет руководил исследовательской службой в CSC Index по бизнес-реин-
жинирингу, работая с тридцатью руководителями высшего ранга во главе инициатив реин-
жиниринга и с основателями этого направления. Получил степень MBA в Калифорнийском
университете в Лос-Анджелесе и степень бакалавра в Стэнфордском Университете.
Майкл Розманн (Michael Rosemann) – профессор информационных систем и соруково-
дитель группы управления бизнес-процессами в Технологическом университете Квинсленда,
Брисбейн, Австралия. Степени магистра (1992 год) и кандидата наук (1995 год) он получил в
Университете Мюнстера в Германии. Основная сфера его интересов – управление бизнес-
процессами, моделирование бизнес-процессов, системы на предприятиях и онтология. В
своих исследованиях на данный момент он среди прочего изучает критически важные фак-
торы успеха моделирования процессов, вопросы моделирования процессов в целом и реаль-
ное применение моделирования процессов. Имеет огромный опыт консалтинга, был совет-
ником по вопросам управления процессами в организациях различных отраслей, включая
связь, банки, страхования, ЖКХ и логистику. Помимо более сорока публикаций в журналах,
семидесяти публикаций по итогам конференций и тридцати пяти глав в книгах, он является
редактором трех книг:
1. Reference Modelling,
2. Business Process Management
3. Business System Analysis and Ontologies, а также
4. членом редакций шести журналов, включая Business Process Management (BPM) Mag-
azine.

Предисловие
Эта книга не должна была стать чем-то необычным, но она необычна. Ее следовало бы
написать уже давно, но ее не написали. Все книги об управлении бизнес-процессами должны
быть похожими на нее. Но не похожи. Книги, которые якобы рассказывают сотрудникам ор-
ганизаций, как сделать нечто, должны быть такими же ясными и понятными, как эта книга.
Но такое случается редко. Уже давно нужно было развеять мифы о загадочности управления
процессами. Но этого тоже не произошло.
Самое замечательное в этой книге – бездна здравого смысла. Она предлагает, казалось
бы, прозаические идеи, вроде той, что в различных обстоятельствах нужно несколько раз-
личных уровней изменений процессов или что для осуществления изменений процессов од-
них только технологий недостаточно. Эти соображения кажутся очевидными, но их редко
встретишь в мире управления бизнес-процессами (BPM).
Краткая история BPM
Вряд ли нова мысль о том, что на работу можно посмотреть как на процесс и затем со-
вершенствовать его. Она зародилась еще на пороге прошлого столетия у Фредерика Тейлора
(Frederick Taylor), а скорее всего, еще раньше. Ф. Тейлор с соратниками разработали совре-
менный промышленный реинжиниринг и усовершенствование, хотя методики ограничива-
лись сферой ручного труда и производственными процессами. Подход Тейлора широко
практиковался в начале прошлого века, но к его середине был порядком подзабыт.
Следующий значимый вклад в управление процессами был сделан Шуартом (Shewart),
Демингом (Deming), Юраном (Juran) и др. в результате комбинации:
 усовершенствования процессов по Тейлору и
 статистического контроля процессов.
Этот вариант управления процессами предусматривал:
 измерение и ограниченную вариативность процессов,
 постоянное, а не эпизодическое улучшение и
 наделение рабочих полномочиями по совершенствованию процессов.
Оказалось, что у японских фирм была:
 бизнес-потребность – восстановление после войны и построение глобальных рынков,
 дисциплина для реализации программ постоянных усовершенствований.
Другие фирмы в других странах взяли на вооружение постоянное усовершенствование и
«всеобщее управление качеством» на основе статистических принципов, но это требует зна-
чительно большей дисциплины, чем большинство из них может обеспечить.
В частности, Toyota приняла такой подход и превратила его в заметное продвижение по
пути управления процессами. Производственная система Toyota (TPS) сочетает статистиче-
ский контроль процессов с непрерывным их изучением в децентрализованных рабочих кол-
лективах, подход по принципу «включения в производственный процесс», сводящий к ми-
нимуму отходы и складские запасы и считающий каждое малое улучшение в процессах экс-
периментом, который нужно спланировать, измерить и извлечь из него уроки. Но лишь не-
сколько фирм преуспели во внедрении TPS, и даже Toyota достигла больше успехов в этом
подходе в Японии, чем на своих зарубежных заводах. Несколько менее жесткий подход к
TPS проявился в «строгих» методиках, принятых недавно многими компаниями США.
Следующий крупный поворот в BPM случился в 90-х годах прошлого века, когда многие
западные фирмы столкнулись с экономическим застоем и жесткой конкуренцией со стороны
глобальных конкурентов, особенно японских компаний. К уже сформировавшимся обоб-
щенным идеям управления процессами реинжиниринг бизнес-процессов принес несколько
свежих подходов:
• кардинальную (не постепенную) перестройку и совершенствование работы;
 • широкий охват многофункциональных бизнес-процессов;
• повышение значимости усовершенствования;
• применение информационных технологий как средство реализации новых методов ра-
боты.
Реинжиниринг стал первым сдвигом в механизмах управления процессами в сторону
фокусировки на таких административных аспектах, как управление заказами и обслужива-
ние клиентов. Не было особого выделения статистического контроля процессов или непре-
рывного совершенствования. Многие фирмы в США и Европе предприняли проекты реин-
жиниринга, но большинство оказалось слишком амбициозными и трудными в реализации.
Сначала реинжиниринг выродился в эвфемизм 1 сокращения штатов, а затем исчез (хотя
налицо некоторые признаки его возрождения).
Самый последний случай всплеска энтузиазма в управлении процессами связан с мето-
дологией «шесть сигм» – подходом, созданным компанией Motorola в 80-х годах и пропа-
гандировавшимся фирмой General Electric в 90-х. В некоторых аспектах «шесть сигм» пред-
ставляет собой возврат к статистическому контролю процессов; а сам термин «шесть сигм»
означает один дефект выхода по шести среднеквадратичным отклонениям распределения
вероятности выхода данного процесса. «Шесть сигм» также предусматривает возврат к
нацеленности на относительно мелкие рабочие процессы и, скорее, постепенные, чем карди-
нальные усовершенствования. Однако большей частью методики совершенствования «шесть
сигм» применялись эпизодически, а не постоянно, и хотя работникам давалась власть улуч-
шать собственную работу, им, как правило, помогали специалисты, имевшие «черный пояс».
Некоторые фирмы стали комбинировать «шесть сигм» с более радикальными подходами,
похожими на реинжиниринг, или со «строгими» подходами – производными TPS. Сейчас
еще слишком рано утверждать, продолжит ли «шесть сигм» существование; я вижу некото-
рые признаки потери импульса, но, несомненно, популярность данной методологии все еще
велика среди многих фирм США.
Подход к BPM в этой книге – достойное внимания слияние всех названных выше подхо-
дов. Здесь нет жесткой опоры на статистический контроль или экспериментирование. Вни-
мание сосредоточено на основах усовершенствования процессов и изменениях. ИТ не счи-
таются стержнем изменений процессов, но и не игнорируются. Рассматриваются все главные
средства понимания, измерения и изменения функционирования процессов, имеющиеся у
организации.
Чему учит история
Какие же уроки дает нам история и как они связаны с книгой, которую вы держите в ру-
ках? Во-первых, ясно, что в управлении процессами в прошлом наблюдались некоторые
странности. Оно было немного незрелым, не сложившимся, принимало различные формы
как прихоти управления. Это не означает, что в самой концепции нет рационального зерна –
я сам ее страстный почитатель. Скорее, менеджеры и фирмы, возможно, хватались за более
модные недолговечные подходы. Некоторые менеджеры даже говорили мне: «Мы реализуем
«шесть сигм», а управлением процессами не занимаемся». Эта неспособность увидеть лес за
отдельным деревом станет проблемой, если (или, более вероятно, когда) начнет таять при-
влекательность отдельного варианта управления процессами.
Возможно, увлечение «новым» подходом (или, по крайней мере, сочетанием известных
идей под новым наименованием) необходимо, чтобы «зацепить» людей, но проблема в том,
что через некоторое время каждый новый вариант увлекает все меньше и меньше. Обычное
управление бизнес-процессами – суть каждого из этих подходов со странностями – может
быть, не столь завлекательно, но уж точно необходимо. Его нужно сначала принять, а затем,
возможно, сохранить на умеренном уровне популярности.
Эта книга замечательно свободна от странностей и является отличным руководством по
фундаментальным принципам управления процессами. Авторы указывают на «миф о зага-
дочности» управления процессами, и они правы в том смысле, что туман в этой области со-
храняется слишком долго.
Также очевидно, что управление процессами, со временем претерпевая изменения, все
больше становится синтетической дисциплиной. Я рад отметить, что в этой книге также
принят синтетический подход к управлению процессами. Каждый новый подход к управле-

1
Не говоря грубее
нию процессами строился на прежнем фундаменте, добавляя один или несколько новых эле-
ментов. В идеале организация могла бы воспользоваться всеми имеющимися элементами
или инструментами для удовлетворения нужд управления процессами каждого отдельного
проекта. Однако сведение всех возможных инструментов управления процессами в одном
едином подходе было бы затруднительно. Все они не уместятся в книге обычного формата.
Поэтому представляется вероятным, что в будущем фирмы будут собирать инструменты,
нужные им под конкретный проект, используя специально выстроенную или сконфигуриро-
ванную методологию. Такой процесс конфигурации потребует либо очень опытных консуль-
тантов управления процессами, которые могли бы собрать подходящие инструменты, либо,
возможно, программного обеспечения, которое поможет менее опытным пользователям
сконфигурировать методологию.
Несмотря на методологические вопросы, управление процессами сводится к изменениям
в людях. Это относится к любым вариациям управления процессами. Как указывают авторы,
люди – это ключ к внедрению новых разработок процессов. Если люди не захотят работать
по-новому, часто очень трудно заставить их сделать это. Так что любые успешные действия
управления процессами требуют энергичных усилий в плане культуры, лидерства и управ-
лении изменениями персонала. Несколько глав этой книги посвящены именно этим вопро-
сам.
Управление процессами не заменяет все и вся в организации – это не панацея. Многие
другие авторы убеждали, что усовершенствование процессов – все, что нужно организации
для успеха. Авторы этой книги такой ошибки не совершают; они утверждают, что управле-
ние процессами должно стать одним из постоянных подходов к управлению организациями.
Оно должно быть согласовано со стратегией, управлением человеческими ресурсами, фи-
нансовым управлением, управлением информацией и другими традиционными сферами
управления, и расширять их. Эти и другие соображения, высказываемые в книге, могут пока-
заться банальными. Они действительно здравые, но недостаточно банальны.
Томас Х. Дейвенпорт
Предыстория
Идея написать эту книгу родилась в 2003 году, когда я занимался начальной стадией
проекта BPM в крупном финансовом учреждении. За три десятилетия консультирования и
работы линейным менеджером в больших и малых организациях у меня развились собствен-
ные интуитивные профессиональные навыки управления проектами и бизнесом. Теперь я
пытаюсь разобраться, как помочь консультантам нашей деятельности в BPM развить навыки
быстрее, чем просто обучаясь в процессе работы.
Я поискал в Интернете и на книжных полках полноценное руководство «как успешно
реализовать проект BPM?». Мне нужна была не просто общая картина, а подробное пошаго-
вое наставление, которое мы могли бы дать клиентам и консультантам, которое вынудило
бы меня меньше прибегать к интуиции (хотя я по-прежнему считаю, что это самое мощное
орудие) и подходить к проектам BPM более формально. Не найдя ничего подходящего, в по-
следующие 12 месяцев я стал записывать свои мысли.
В середине 2004 года мы получили резюме Йохана из Голландии, который хотел уехать
в Австралию из своей страны, где он возглавлял деятельность BPM фирмы Sogeti (часть
компании Cap Gemini). Йохан также работал над разработкой общей схемы для проектов
BPM и присоединился ко мне в консалтинговой деятельности по BPM компании TouchPoint.
Вскоре мы объединили свои усилия по написанию этой книги.
Джон Джестон (John Jeston)

Меня всегда поражало, что в наше время профессиональные знания и умения консуль-
танта BPM по-прежнему большей частью основаны на опыте, и их седые волосы – все еще
яркое тому подтверждение. BPM по-прежнему больше искусство, чем наука. Существует
очень немного источников информации, на которые можно положиться при реализации про-
екта BPM:
 очень мало хороших книг, охватывающих все нужные аспекты;
 результаты поиска в Интернете перегружены рекламой поставщиков решений;
 очень немногие семинары или курсы обучения оправдывают свои обещания.
Я всегда был страстным поборником обмена опыта и знаниями – начиная с моей первой
работы в ООН, где не только достигались результаты, но и передавались знания.
 За время своей карьеры в Sogeti я имел счастливую возможность разрабатывать эталон-
ные справочные модели и руководства; проводил обучение BPM и читал лекции, а также ор-
ганизовывал экспертную группу BPM и голландский Форум BPM. Йерен Верстег (Jeroen
Versteeg) и Клаас Бронгерс (Klaas Brongers) оказали мне большую помощь в этом деле.
Написание книги, сочетающей как комплексный всесторонний взгляд, так и необходи-
мые подробности, было давно лелеемой мечтой. Когда я стал работать в компании
TouchPoint, Джон Джестон рассказал мне о своих планах и показал набросок общей схемы. Я
понял, что эта мечта осуществится.
Йохан Нелис (Johan Nelis)

Введение
Глобализация ведет к переизбытку производственных мощностей или потенциала по-
чти во всех отраслях, а это является причиной того, что все больше товаров и услуг ста-
новятся товарами повседневного спроса, либо приводит к снижению цен. Поэтому успех
сопровождает тех, кто умеет лучше всего приспосабливаться. При этом инновации мето-
дов работы предприятия становятся столь же важными, как и инновации продуктов, ко-
торые продает компания.
Луис В. Герстнер, мл. (Louis V. Gerstner Jr), {19}
Осторожно относитесь к модным словечкам, методам управления и новейшим веяниям
вроде EVA, TQM, системы сбалансированных показателей (BSC), рационализации деятель-
ности на основе сравнения (benchmarking), BPR, шести сигм, а теперь и BPM – все они обе-
щают много и часто считаются панацеей. Менеджеры могут спрятаться за этим словечками и
сказать: «Ну, я применил эту штуку, как было сказано, но она так и не заработала».
Эти «новейшие методики» кажутся простыми в применении, но в реальной жизни они
сложны. Менеджерам по-прежнему необходимо критически оценивать свою организацию и
вносить изменения, которые нужны именно их предприятию, – «по отдельному заказу».
Времена бурных перемен в организациях и в обществе налагают на руководителей и ме-
неджеров особые обязанности лидеров при прорыве через существующие границы в два-
дцать первый век:
• развитие глобального потенциала;
• позиционирование на дальнейший рост;
• неустанное совершенствование бизнеса;
• управление организацией, «глядя на нее со стороны, сверху».
Стейс и Данфи (Stace, Dunphy), {71}
Петер Дрюкер (Peter Drucker) ({16} – выделено авторами) утверждал, что: … единствен-
ный колоссальный вызов, стоящий перед менеджерами в развивающихся странах мира –
поднять производительность работников сферы знаний и услуг. Этот вызов десятиле-
тиями будет доминировать в области управления, определять конкурентную эффектив-
ность компаний и саму ткань общества, а также качество жизни в развитых странах.
 Что есть продуктивность, или постоянное совершенствование бизнеса?
Широко распространено мнение, что продуктивность (или постоянное совершенствова-
ние бизнеса) означает:
 способность все делать быстрее с меньшими затратами. Разумеется, это подходящий
критерий и, вероятно, самый общий. Нельзя не учитывать также:
 качество и вопросы обслуживания клиентов;
 скорость ее реакции на запросы рынка, внедрение инноваций продуктов или услуг, а
также способности изменяться в соответствии с требованиями рынка. Сейчас много говорят
о том, что эту самую подвижность (маневренность) предприятию может обеспечить внедре-
ние автоматизированного управления бизнес-процессами.
Компании крайне важно определить тип продуктивности или производительности, кото-
рый важен или даже критически важен для достижения ее стратегической цели. Простой от-
вет на этот вопрос дают все вышеперечисленные характеристики (время, затраты, качество,
обслуживание клиентов, восприимчивость к рынку и маневренность бизнеса). Однако нелег-
ко одновременно преследовать все эти цели, не имея структурированного и планового под-
хода.
В главе 13, где рассматривается стратегия организации, указывается, что организация
должна выбрать одно из трех стратегических направлений {73}:
1. доверительные отношения с клиентом – лучшее комплексное решение для клиента.
2. Совершенство функционирования – по затратам и себестоимости.
3. Обеспечение лидирующего положения продукта – продукт должен быть лучшим.
М. Триси (Treacy, M.) и Ф. Виерсма (Wiersma, F.) отмечают, что невозможно преуспеть в
достижении сразу трех целей. Необходимо выбрать одну из них, в противном случае, по сло-
вам Майкла Портера (Michael Porter) {58}, предприятие окажется в положении Буриданова
осла, не достигнув ни одной цели, и в конечном итоге либо исчезнет, либо не обеспечит хо-
рошей продуктивности.
Именно лидеры должны:
 выбрать приоритетную стратегию для организации, а затем
 выделить процессы, которые необходимо реорганизовать или создать для достижения
желаемого результата.
Все больше лидеров осознают, насколько это важно для реализации стратегии и целей
организации.
Эта книга о том, как обеспечить лидерство в организации, осознавая суть управления
бизнес-процессами и его важность для организации, и как это осуществить на практике. В
ней также рассмотрена общая схема и комплекс инструментов и методик, которые состав-
ляют практическое руководство по успешной реализации проектов управления бизнес-
процессами.
Однако читатель должен ясно понимать, что управление бизнес-процессами – весьма
сложная работа. Это не роман, который читают от корки до корки, а, скорее, справочник для
организаций, реализующих проекты управления бизнес-процессами, представляющий все-
сторонний подход. Различные этапы и шаги в описываемой схеме настолько сложны и так
сильно взаимосвязаны, что менеджеру, не имеющему опыта управления бизнес-процессами,
при первом чтении книга покажется необъятной. Но после прочтения, изучения и примене-
ния материалов книги сложности и взаимозависимости станут понятнее, и постепенно вста-
нут на свои места.
Книга состоит из четырех частей:
1. в части I рассмотрено десять распространенных вопросов об управлении бизнес-
процессами (англ. BPM) и даются ответы на них. Ответы адресованы высшим руководите-
лям организации, и в них выдержан всесторонний обобщенный подход к управлению биз-
нес-процессами на уровне организации в целом. Вовсе не обязательно заниматься этими во-
просами и ответами на них до внедрения или реализации проекта BPM внутри организации.
Ответы даются не на уровне проекта, а на уровне всей организации. Они призваны обрисо-
вать общую картину, способствовать пониманию управления бизнес-процессами и переори-
ентированию организаций на процессы.
2. Часть II описывает общую схему и предназначена для практиков BPM. В ней подроб-
но рассматривается схема проекта BPM, включая два различных наиболее вероятных момен-
та запуска такого проекта и выбор четырех наиболее вероятных сценариев его реализации.
После этого приводится десять этапов и три «ключевых компонента» проектов BPM. Этапы
1 и 2 (стратегия организации и архитектура процессов) предназначены, главным образом,
для организаций, зрелых в смысле BPM, и их не всегда надо полностью предусматривать до
начала проекта. Этапы 3–10 уже базируются на проекте BPM и описывают действия и меро-
приятия, необходимые для успешного его выполнения.
Полнота и характер реализации каждого этапа схемы зависят от того, каким образом ор-
ганизация пришла к решению о необходимости проекта BPM и выбранного сценария реали-
зации (типа проекта). На выбор сценария оказывает влияние:
 BPM,
 зрелость организации и
 вовлеченных в проект руководителей в области процессов, а также
 конкретные условия и обстоятельства в организации или структурном подразделении,
инициирующем проект.
3. Часть III также рассчитана на руководителей организации и дает возможность загля-
нуть внутрь механизма, позволяющего определить готовность организации или структурно-
го подразделения к BPM и вживлению BPM в организацию, чтобы обеспечить постоянное
совершенствование бизнес-процессов.
4. Часть IV адресована практикам. Она включает ряд приложений, связанных со всеми
этапами общей схемы и дающих в руки группы проекта практический инструментарий, по-
яснения и помощь в успешной реализации проекта BPM.
Книга также содержит более пятидесяти конкретных примеров, иллюстрирующих раз-
личные ее положения. Два примера достаточно пространны, чтобы показать использование
этапов общей схемы целиком на практике.

Часть I. Часто задаваемые вопросы

Важно не переставать задавать вопросы
Альберт Эйнштейн

Как отмечено во введении, часть I адресована руководителям и посвящена общим во-

просам, в ней дается обобщенно-комплексная картина организации, ориентированной на
процессы. Нет необходимости изучать все эти вопросы, перед тем как пуститься в плавание
по водам BPM, но на каком-то этапе их придется рассмотреть.
Сначала в части I поясняется, почему BPM кажется многим не очень понятным, и чем
оно отличается от того, что было раньше. Главы 1 и 2 отвечают на вопросы «Как развенчать
миф о BPM?» и «Что такое BPM?», соответственно.
По нашему опыту реализации проектов и программ BPM в различных организациях,
важно отладить и усовершенствовать процессы до того, как браться за их автоматизацию.
Это обсуждается в главе 3.
Важно, чтобы организация в целом и руководство понимали, когда следует внедрять
BPM, каковы основные приводные ремни и рычаги проекта. Осознав, что проект BPM – дело
полезное, нужно решить, кого к нему привлечь. Эти вопросы освещены в главах 4 и 5.
Имеется довольно обширная литература о том, как выстроить BPM в русле общей стра-
тегии организации, а также о необходимости архитектуры процессов. В главе 6 объясняется,
почему это так важно.
Энтузиастам BPM внутри организации может оказаться затруднительно убедить руко-
водство в полезности данного начинания. В главе 7 успешный менеджер европейского аль-
янса одной крупной организации программного обеспечения BPM рассказывает, как ему
удается убедить другие организации взяться за BPM.
Наконец, главы 8, 9 и 10, соответственно, обращаются к трем важным вопросам:
1. каковы решающие факторы успеха проекта BPM?
2. Каковы критически важные аспекты внедрения решения BPM?
3. Почему необходим структурный подход к внедрению BPM?

Всякому прогрессу человечества предшествовали новые вопросы.

 Глава 1. Как развенчать миф о загадочности управления бизнес-процессами. Крат-
кая история управления бизнес-процессами

Путь к управлению бизнес-процессами (BPM) был труден, он позволил собрать опыт

разнообразных удачных и неудачных попыток добиться эффективности организации за счет
опоры на процессы.
Возможно, стоит посвятить несколько строк очень краткой новейшей истории управлен-
ческой ориентированности на бизнес-процессы.
В 80-х годах прошлого века значительное внимание привлекало всеобщее управление
качеством (TQM – Total Quality Management), за которым в начале 90-х годов последовал ре-
инжиниринг бизнес-процессов (BPR – Business Process Reengineering), пропагандировавший-
ся М. Хаммером (Hammer) и Дж. Чампи (Champy). Довольно пестрая история концепции ре-
инжиниринга знает примеры блистательных успехов и сокрушительных провалов.
Следующей громкой концепцией, пришедшей на смену реинжинирингу в середине –
конце 90-х годов, стало планирование ресурсов предприятия (ERP – Enterprise Resource
Planning). Предполагалось, что системы ERP обеспечат усовершенствованные способы
управления функционированием организаций, и многие поставщики утверждали, что такие
системы «решат все ваши проблемы». Разумеется, системы ERP не решали проблем процес-
сов, как не обеспечивали возможной эффективности и производительности процессов.
В конце 90-х годов и в начале нового века получили распространение различные систе-
мы управления взаимоотношениями с клиентами (CRM – Customer Relationship
Management), в которых главный упор делался на профиль клиента, его «послужной список»
и опыт. Хотя здесь центр внимания смещался на службы, непосредственно работающие с
клиентами (фронт-офис), процессы служб обеспечения (бэк-офиса) при этом не улучшались.
Совсем недавно стала получать признание и распространение концепция «Шесть сигм».
По словам М. Хаммера {24}, «выдвинуть идею просто, трудно добиться результата. Рефор-
мы вязнут и погибают в окопах». А кто сидит в «окопах»? – вы, я и все остальные люди. Ре-
формы, навязываемые «людям в окопах», не преуспеют, если они оторваны от эволюционно-
го или революционного процесса: волевое лидерство имеет свои пределы. Переход от бю-
рократии машинного века к гибким, самоуправляемым группам требует психологической
подготовки огромных масс обычных менеджеров и рядовых сотрудников.
М. Хаммер, {25}

Очередная «гранд-идея», или как рождаются мифы?!

У нас появилось еще одно сокращение из трех букв: BPM! Почему же BPM считается
следующей «грандиозной концепцией» и почему все подобные концепции неизменно при-
ходят и уходят?
Создание очередной грандиозной концепции обычно проходит в четыре этапа:
1. пропагандисты концепции (поставщики решения/аналитики и т. п.) продвигают ее
на рынок, «раскручивают» с помощью своих рекламных материалов и акций продаж, в про-
молитературе, приводя результаты исследований и конкретные примеры успешного приме-
нения.
2. Затем пропагандисты пытаются низвергнуть все предшествующие «старые гран-
диозные концепции» и представить новую концепцию как наилучшую.
3. Следующий шаг – сделать новую концепцию максимально простой, чтобы ее мог-
ли понять ответственные за принятие решений руководители, при этом посыл состоит в том,
что все это просто, а значит, может быть легко реализовано.
4. Пропагандисты идеи (особенно поставщики продукта) разворачивают маркетинг
разработанных продуктов и предложений услуг с новой этикеткой (в нашем случае BPM),
даже если предложения не отвечают общепринятому пониманию содержимого этой этикет-
ки. В результате у содержания этикетки появляется столько определений, сколько имеется
поставщиков продукта.
В нашем случае новая этикетка называется BPM, и уже начинают появляться те же са-
мые проблемы. Если посмотреть на подобные «грандиозные идеи» в историческом ракурсе,
все они связаны одной нитью: они посвящены бизнес-процессам и пытаются их улучшить.
 Все – и поставщики, и консультанты – хватаются за новую идею, а она часто и вправду
бывает очень хороша, и раздувают ее, пока она не созреет и ею можно будет либо восполь-
зоваться, либо реализовать каким-либо приемлемым способом.
Цикл «раскрутки» BPM, представленный на рис. 1.1, показывает обобщенную картину
продвижения «процессного цикла» за последние двадцать лет.
«Шесть сигм» были придуманы в 1986 году, что вызвало осознание «процессов». В июле
1990 года последовала статья М. Хаммера и Дж. Чампи «Не автоматизируйте. Ликвидируй-
те» в журнале «Гарвардский бизнес-обзор» (Harvard Business Review) {27}, и началось дви-
жение реинжиниринга бизнес-процессов (BPR). Хотя BPM уже обсуждается некоторое вре-
мя, книга Смита и Фингара 2002 года «Управление бизнес-процессами: третья волна» вызва-
ла существенный интерес и споры {68}. Сегодня можно утверждать, что BPM – это самый
важный вопрос на повестке дня управления и руководства.

Что загадочного в BPM?

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

Главные черты «мифичности» BPM и реальность

Таблица 1.1. Реклама и реальность

«мифы» о BPM реальность BPM

1. BPM лучше, BPM, несомненно, позволяет внимательнее отслеживать совершен-
чем предыдущие кон- ствования процессов во многих организациях. BPM вновь заставила
цепции усовершен- многих исследователей и аналитиков сконцентрировать внимание на
ствования бизнес-процессах, и было создано несколько специальных организаций, ис-
процессов ключительно занимающихся вопросами процессов (например,
BPMI.org / BPM Group). Это, разумеется, положительное явление,
поскольку обсуждение стандартов и BPM в целом поднимает значи-
мость предмета и формирует рынок. Воспринимается и накопленный
опыт, например, реинжиниринга. Главное здесь то, что BPM прине-
сет столько пользы, сколько может дать организованность и
управляемость
2. BPM задей- На сегодня нет полностью автоматизированных полномасштабных
ствует новые усовер- сквозных по предприятию внедрений BPM, чтобы как-то оправдать
шенствованные тех- это утверждение. По нашему опыту, технологии не должны быть
нологии первоначальной целью реализации BPM. Необходимо, чтобы на
начальном этапе работа увязывала пересмотр действующих процес-
сов с задачей повышения эффективности и продуктивности (важ-
ность определения цели процесса подробнее обсуждается в главах
 14, 15 и 17). Хотя вновь сформированные процессы могут предпола-
гать (если это целесообразно) наличие автоматизации, существенно-
го улучшения процессов можно достичь, не обращаясь к технологи-
ям. Люди склонны увлекаться разнообразными «наворотами» и ви-
дят не то, что технологии должны дать предприятию, а то, что
они могли бы дать
3. Разработана Нужна осторожность – методология (или схема) может оказать-
вполне сформиро- ся, как спасательным кругом, так и камнем на шее. Вопрос в том,
вавшаяся цельная ме- как ею воспользоваться
тодология BPM, но
есть и методологии
отдельных компонен-
тов, и несколько пол-
ностью готовых
сквозных методоло-
гий внедрения ком-
плексных решений
BPM.
4. BPM – это Нет ничего дальше от истины. В любой реализации BPM много эле-
просто (на самом деле ментов и составляющих, и подробное их обсуждение – одна из целей
данную концепцию этой книги. Не надо пытаться решить все проблемы организации
нередко слишком сразу с помощью BPM. Начните с малого – с одного проекта. По
упрощают) мере созревания организации BPM можно расширять
5. Для внедрения Здесь многое зависит от зрелости, квалификации и умений, а также
BPM нужны люди опыта персонала. Несомненно, внешние консультанты могут ока-
извне зать помощь в роли либо наставника, либо консультанта, если уро-
вень зрелости и компетентности в самой организации недостато-
чен. Опытный внешний менеджер проекта BPM может придать
проекту необходимую направленность, которую иногда не могут
обеспечить менеджеры проекта внутри организации

Синдром «вершины айсберга»

Над водой обычно видна только верхушка айсберга (10 % всей массы). BPM часто по-
хож на айсберг: люди и организации видят только то, что над водой. Интересно отметить,
что каждый наблюдатель видит над поверхностью что-то свое. Поставщик продукта видит
технологию; аналитик процессов видит … конечно, процессы; подразделение кадров – смену
управления; подразделение информационных технологий – внедрение технологий; бизнес-
руководство – краткосрочные преимущества (быстрый выигрыш), сокращение затрат и про-
стые меры для усовершенствований, а менеджер проекта – выполнение краткосрочных задач
и достижение результатов проекта.
Часто под «восприятием» (надводной, видимой частью) понимают графическое испол-
нение «красивых картинок» или моделей процессов, тогда как «реальность» означает реали-
зацию этих процессов и получение выигрыша в бизнесе. Прекрасная стратегия бесполезна,
если она неправильно реализована.
К сожалению, внедрение BPM – это многогранная работа, и на рис. 1.2 показано, что
«реальность» – это то, что находится ниже поверхности воды. Риск неудачи проекта BPM
растет, если не уделить практическое внимание «реальности», связанной с внедрением BPM.
Однако недостаточно просто уделить внимание этой «реальности» – организация должна
видеть ее. Судно может проплыть вплотную к айсбергу с одной стороны и ни на что не
наткнуться, но удариться, повторив эту попытку с другой стороны, и затонуть. Видение про-
блем и способов их решения – это важная часть рабочего процесса.
 Теперь кратко рассмотрим одну из «реальностей».
Исследуя «реальность»
Самая важная составляющая любого внедрения BPM – управление организационными
изменениями и воздействиями на соответствующий персонал (кадры). Как упоминалось вы-
ше, внедрение и его успех зависят от «людей в окопах». Люди и их участие во внедрении –
это ключевые фигуры процесса, и поэтому исключительно важен всесторонний подход к во-
просам работы с людьми, к роли культурных аспектов и «фабрики процессов» в управлении
организацией. Ведущая роль в привлечении «людей в окопах» принадлежит их непосред-
ственным руководителям. Именно эти менеджеры нижнего звена должны включиться в ра-
боту. Но один менеджер проекта или проектная группа не смогут добиться вовлечения лю-
дей самостоятельно, в одиночку. (Замечание: так что же такое «фабрика процессов»? Любая
организация, в которой через вспомогательные подразделения (бэк-офис) проходят огром-
ные объемы, и где существует большое количество «точек обмена», может быть названа
«фабрикой процессов».)
Именно люди определяют успех (или неуспех) проекта BPM. Можно иметь самые эф-
фективные и высокопроизводительные новые или перестроенные процессы в мире, но если
не удастся научить людей эффективно пользоваться или даже просто пользоваться ими, то
все напрасно. Людей необходимо целиком и полностью вовлечь в процесс развития в каче-
стве его основной движущей силы. С ними нужно советоваться, регулярно общаться, при-
слушиваться к ним и обучать их. Если люди не понимают причин внедрения новых процес-
сов и необходимости изменений уже существующих, как можно рассчитывать, что они при-
мут новшества и возьмут на себя ответственность за них?
Людям надо четко разъяснить, чего от них хотят и как они встраиваются в новые струк-
туры и процессы. Показатели эффективности их работы следует разработать в сотрудниче-
стве и согласии с ними.
Какова же роль руководства в таких преобразованиях? Может показаться очевидным,
что менеджеры должны управлять функционированием организации и «фабрикой процес-
сов», но на самом деле это совсем не то, чем занимается большинство современных мене-
джеров. По нашему опыту, за редкими исключениями, у сегодняшних менеджеров все боль-
ше времени уходит на то, чтобы отреагировать на критическую ситуацию и «вылечить»
симптомы, а не болезнь, – такой тип работы принято называть кризисным управлением.
Не надо думать, что я критикую менеджеров. В целом, это напряженно и добросовестно
работающие люди, которые прекрасно справляются со своим делом, работая инструментами,
которые есть в наличии. В любом проекте BPM необходимы значительные усилия, чтобы
наладить работу с управленческим персоналом и определить, какая информация нужна ме-
неджерам, чтобы они могли реально управлять предприятием. Менеджеры должны глубоко
и всесторонне понимать, как функционирует предприятие, какие сводки и отчеты требуются,
чтобы перейти от реактивного метода управления к профилактически упреждающему, а за-
тем и к предвидящему. Именно такая эволюция зрелости управления обеспечит организации
долгосрочный непрерывный и устойчивый рост производительности.

Управление изменениями и измерение производительности

Составляющие элементы управления изменениями персонала (т.е. людей) должны учи-
тывать культурную среду организации и подстраивать ее под новую поведенческую модель
менеджеров, трансформируемую в поведенческую модель людей, которыми они управляют.
 Чтобы поддержать усилия, направленные на реализацию культурных изменений, необ-
ходимо состыковать побудительные мотивы менеджеров с доступной управленческой ин-
формацией, целями процессов и стратегией организации. По ходу измерения производи-
тельности стимулы и целевые задачи должны быть хорошо известны и реалистичны. Они
также должны оставлять лучшим работникам возможность выходить за границы нормати-
вов. Необходимо также обеспечить достойное вознаграждение. При этом не всегда возна-
граждения и стимулы переводятся в денежную форму, кадровые подразделения должны
проявить изобретательность в использовании неденежных вознаграждений. Трудность за-
ключается в том, чтобы измерить такое изменение эффективным и приемлемым способом.
Заключение
Многие до сих пор не до конца понимают, что же такое BPM. И это неудивительно, по-
скольку даже само BPM-сообщество не выработало общепринятого определения и общих
подходов. BPM целиком связано с эффективным и продуктивным управлением бизнес-
процессами, при этом персонал (люди) являются сердцевиной бизнес-процессов. Поэтому
необходимо сделать их неотъемлемой частью проекта. Как очень точно сформулировал Сти-
вен Шварц из IBM, «у всех есть планы рационализации и усовершенствований. Однако
настоящие преобразования наступают тогда, когда принимается решение, что это уже долж-
но быть не планами, а стратегией бизнеса». Нам представляется, что это положение – одно
из ключевых для успешной реализации проекта BPM. Не слишком занижая объем работ по
внедрению, можно сказать, что сам проект – вещь довольно простая. Ключевым фактором
является постановка усовершенствования процессов как основы практического управления,
а этого нельзя достичь эффективным образом, не имея возможности управлять своими про-
цессами с упреждением и на перспективу.

Глава 2. Что такое управление бизнес-процессами

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

Предостережение
Бытует опасное заблуждение, что приобретение программного средства моделирования
процессов решает все проблемы, и процессы после этого усовершенствуются сами собой.
Нет ничего более далекого от истины. Моделирование процессов – это всего лишь про-
граммный инструмент, и без методологии или общей схемы, квалифицированного персона-
ла, который умел бы его применять, и искреннего стремления руководства организации оно
бесполезно.
Выбор программного средства моделирования процессов описан в Приложении L. Как и
многие другие сокращения, появившиеся в последнее время, вроде CRM и ERP, BPM неред-
ко применяется и трактуется неправильно.
В настоящий момент понятием BPM по-разному оперируют:
• поставщики программных продуктов, которые сосредоточены лишь на технологи-
ческом решении усовершенствования процессов;
• другие поставщики программных продуктов, для которых BPM означает модели-
рование бизнес-процессов или управление эффективностью работы предприятия или орга-
низации;
• консультанты, специализирующиеся в реинжиниринге бизнес-процессов и приме-
няющие BPM, для того чтобы продолжить свою миссию;
 • менеджеры, которые изо всех сил бегут за модой на BPM, но совершенно не пони-
мают, куда они в результате попадут;
• аналитики бизнес-процессов, для которых BPM – это возможность расширить свои
устремления в области моделирования процессов.
Многие наблюдатели отрасли и вендоры дают определения понятия BPM, в которых
технология (средства автоматизации) фигурирует в качестве непременного и важного ком-
понента управления бизнес-процессами; они утверждают, что BPM и есть технология. Но
если взглянуть на BPM с точки зрения простого здравого смысла, то понятно, что BPM опи-
сывает управление бизнес-процессами.
Имея в виду эту простую мысль и сосредоточив основное внимание на организации,
предложим такое определение управления бизнес-процессами: достижение целей организа-
ции посредством совершенствования, управления и контроля основных бизнес-процессов.
Важно, чтобы смысл слов, выделенных курсивом в приведенном выше определении,
воспринимался всеми одинаково, поэтому каждое из них снабжено точным определением и
помещено в табл. 2.1.
 Таблица 2.1. Термины, входящие в определение понятия «управление бизнес-
процессами»
Термин Содержание
Достижение Реализация стратегической цели, сформулированной в стратегическом плане организа-
ции. На уровне проекта это означает создание ценности или извлечение пользы или вы-
годы для организации, как указано в технико-экономическом обосновании проекта
Цели Могут лежать в широком диапазоне: от стратегической задачи организации до задач
отдельного проекта. Суть заключается в достижении результатов или решении задач
организации. Само по себе ВМР целью не является: скорее, это средство достижения
цели, решения совершенно реальных задач
Организация Предприятие или его часть, например, обособленное или самостоятельное структурное
подразделение. Речь идет о сквозных процессах, связанных с данной частью организа-
ции. Такой подход призван обеспечить порядок в ведении дел
Совершенствование Как сделать бизнес-процессы более эффективными и продуктивными
Управление Измерение показателей эффективности работы людей и процессов, а также управление
ими. Речь идет об организации всех необходимых компонентов процессов: расстановка
людей, подбор по их квалификации, мотивирование, измерение эффективности работы,
вознаграждение, сами процессы, а также система и структуры, необходимые для обеспе-
чения процессов
Контроль Сквозное - от начала до конца - управление бизнес-процессами; включает полный цикл
Деминга: «план-действие-сверка-реакция» (Plan - Do - Check - Act – PDCA). Неотъемле-
мая составляющая контроля – возможность правильного измерения. Невозможно кон-
тролировать и управлять тем, что невозможно измерить
Основной процесс Не все процессы обеспечивают прямой вклад в достижение стратегических целей орга-
низации. Основные процессы такой вклад обеспечивают
Бизнес Внедрение ВМР должно влиять на бизнес, обеспечивая выгоды и преимущества. Оно
должно быть сосредоточено на бизнес-процессах, являющихся ключевыми для главной
бизнес-деятельности организации. Они обеспечивают достижение ее стратегической
цели
Процессы Определений понятия «процесс» столько же, сколько самих процессов. Нам импонирует
определение Роджера Берлтона: «настоящий процесс включает все, что необходимо че-
ловеку, заинтересованному в результате, для получения ожидаемого результата». Эта
фраза содержит суть настоящего сквозного процесса: от исходного механизма включе-
ния процесса до окончательного удовлетворения заинтересованных лиц. Далее Берлтон
добавляет, что «окончательная проверка полноты процесса заключается в том, выдает ли
он четкий продукт или услугу внешнему заинтересованному лицу или другому внутрен-
нему процессу»

Сегодня все склонны соглашаться (и наблюдать эту тенденцию приятно), что BPM – это
наука управления бизнес-процессами.
Пол Хармон из Business Process Trends {31} определяет BPM как «управленческую дис-
циплину, направленную на совершенствование работы предприятия путем управления его
бизнес-процессами».
Таким образом, управление процессами – это составная часть «обычного» управления.
Руководству и ведущим сотрудникам важно осознавать, что нет финишной черты в совер-
шенствовании бизнес-процессов; это программа, которая должна работать постоянно.
Итак, BPM – это:
• больше, чем просто программное обеспечение;
• больше, чем простое совершенствование или реинжиниринг процессов – отрабаты-
ваются и вопросы управления;
• не просто модное течение, а составная часть управления;
• не только моделирование – анализа требует и внедрение и реализация этих процес-
сов.
И последнее (по порядку, но не по важности) замечание. Как управленческая дисципли-
на, BPM требует:
 наличия «сквозной» комплексной картины организации и
 достаточного здравого смысла
И того, и другого часто не хватает.
 Глава 3. Почему важно усовершенствовать бизнес-процессы, перед тем как их ав-
томатизировать

Правила любой технологии:

1. автоматизация эффективной операции повышает эффективность
2. автоматизация неэффективной операции увеличит неэффективность.
Билл Гейтс, Microsoft Corporation

Легкие решения сложных проблем очень соблазнительны. В мире бизнеса нужно уметь
быстро решать проблемы и сразу продвигаться вперед. Когда с работой трудно справиться
достаточно быстро, оказывается, что ее можно автоматизировать!
Автоматизация офисного труда за последние 100 лет доведена до такой степени совер-
шенства, что сегодня автоматизируется почти все: написание писем, бухгалтерия, составле-
ние отчетов, учет имущества и складских запасов, продажи и обработка заказов, документо-
оборот и управление документацией. Поэтому первый соблазн при столкновении с пробле-
мами производительности, эффективности и управления бизнесом – приобрести автоматизи-
рованное решение проблемы.
В чем проблема
Сегодня предприятия, особенно крупные организации со сложным комплексом сервис-
ных продуктов, начинают осознавать, что возможности их систем ИТ (IT – Information
Technology) в усовершенствовании работы предприятия ограничены. Даже если основные
системы работают эффективно и производительно (что случается далеко не всегда), стано-
вится все труднее опережать конкурентов в повышении эффективности работы предприятия,
в целом, и качества обслуживания, в частности, до уровня, соответствующего ожиданиям
клиентов и акционеров. Даже Билл Гейтс, ярый сторонник технологий автоматизации, при-
знает, что автоматизация дает эффект только в применении к эффективно организованной
работе.
Итак, решив насущные проблемы автоматизации функциональных систем предприятия
и добившись большей части просто получаемых выгод и преимуществ, организации теперь
обращаются к более сложным и системным областям эффективности функционирования,
чтобы добиться усовершенствования работы предприятия за счет скачкообразных измене-
ний, т.е. к самим процессам функционирования бэк-офиса (вспомогательных служб и служб
обеспечения основной деятельности). Что подсказывает нам интуиция для решения этих за-
костеневших в своей неэффективности функциональных служб?
Правильно. Автоматизируем их! В конце концов, автоматизация сработала для систем
управления объемами производства и производительностью, и сейчас на рынке полно по-
ставщиков, наперебой предлагающих решения документооборота и графического представ-
ления документов для конкретной отрасли или среды деятельности, часто уже готовые к ис-
пользованию без настройки на конкретного пользователя.
Почему же это не работает - главным образом, есть две причины - в этой книге син-
дром:
1. «черного ящика» - ситуация, когда руководители смотрят на процесс как на непонят-
ную, непознаваемую «вещь в себе». Детали им неизвестны, но каким-то образом результат
на выходе из «черного ящика» достигается. Руководители чувствуют, что, возможно, сами
процессы не столь эффективны и продуктивны, как могло бы быть (поскольку не ведутся
измерения качества и объемов проделанной работы). Но, по крайней мере, процессы рабо-
тают, а менеджеры опасаются что-либо менять, потому что перемены могут разрушить
«хрупкое» равновесие в «черном ящике», а устранить проблему тяжело, не понимая ее. По-
этому автоматизировать «черный ящик» проще – это становится проектом, а предприятия
реализуют «проекты».
2. Поверхностного взгляда: процессы и связанный с ними персонал рассматриваются
как «священная корова» – руководители не могут или не хотят обсуждать эффективность и
результативность процессов или ставить жесткие вопросы. Они склонны «скользить взгля-
дом по поверхности» проблемы и боятся заглянуть в суть – лечение симптомов, а не болез-
ни. В таких организациях привнесение новых технологий представляется намного более
простой задачей, поскольку разговора о процессах или персонале не заходит – речь идет
только о технологии.
 Если неэффективность бизнес-процессов можно легко устранить, автоматизировав их,
почему организации частенько нанимают консультантов после приобретения дорогостояще-
го продукта автоматизации процессов документооборота, который так и не решил проблему?
Почему автоматизация не дают ожидаемого выигрыша и преимуществ? На деле в организа-
циях часто наблюдается увеличение бумаготворчества или объема переделываемой работы и
снижение качества после автоматизации ключевых бизнес-процессов и процессов докумен-
тооборота.
Почему автоматизация не дает ожидаемого результата
Ответ кроется в замечании Билла Гейтса в эпиграфе. Сама по себе автоматизация чего-
либо не решает коренные проблемы, а лишь ускоряет их выявление, способствует росту их
количества и частотности. Идею замены неисправного механизма чем-то значительно луч-
шим почти никогда не удается реализовать в зрелой организации, поскольку трудно вносить
мгновенные крупномасштабные изменения в процессы и культуру предприятия по ходу его
работы. В лучшем случае находится компромиссное решение, часто с заметными превыше-
ниями сроков реализации и бюджета проекта. В худшем случае проект проваливается пол-
ностью и статус-кво сохраняется. В обоих случаях ожидаемые преимущества не реализу-
ются, а уровень удовлетворенности клиентов может резко упасть.
Возникает вроде бы очевидный вопрос: «Почему бы организациям не отладить процессы
до принятия решения об автоматизации?»
В большинстве крупных фирм базовые процессы бэк-офиса оставались большей частью
неизменными на протяжении многих лет и даже десятилетий. Например, в сфере финансо-
вых услуг базовые банковские процессы, процессы обработки инвестиций и страхования пе-
реходили из поколения в поколение.
В ретроспективном плане организации были не способны легко справиться с проблема-
ми функционирования бэк-офиса (бизнес-процессами), поскольку считали их весьма про-
стыми (все, что было необходимо для их решения, – автоматизация, чтобы ускорить сами
процессы и исключить человеческий фактор из формулы). Другие, наоборот, считали данные
проблемы очень сложными (слишком трудными, чтобы руководство могло их решить, пото-
му что у него не хватало для этого знаний и квалификации). В таком случае было очень со-
блазнительно приобрести средство решения проблемы – опять приходим к простому вариан-
ту.
Чему учит история
В главе 1 отмечалось, что ни одна из таких концепций управления, как TQM, BPR, CRM,
ERP или «Шесть сигм», не дает полного комплексного решения для достижения преиму-
ществ, которые необходимы предприятиям, чтобы поднять эффективность работы бэк-
офиса. Что же сегодня заставляет руководство компаний думать, что с автоматизацией BPM
все будет по-другому?
У автоматизации BPM есть возможность содействовать успеху, если процессы сначала
усовершенствуются и учтены все остальные аспекты проекта BPM. Но правилен ли поход к
изменениям совершенствования бизнес-процессов?
Организации твердят, что годами непрерывно отлаживали бизнес-процессы, так что они
готовы к автоматизации. Так ли это? Является ли постоянное совершенствование правиль-
ной стратегией и не борется ли непрерывное совершенствование с симптомами, а не с самой
болезнью?
Постоянное совершенствование, даже если оно целесообразно, – это чрезвычайно слож-
ная программа, рассчитанная на непрерывную многолетнюю реализацию, что требует от ме-
неджеров управления предприятием, а, к сожалению, большинство менеджеров не контро-
лируют свое предприятие. Они в основном работают по принципу «первой помощи», т.е.
постоянно решают краткосрочные тактические задачи. Вопрос же по существу заключается
в том, сколько времени менеджеры фактически тратят на предупреждение проблем, занима-
ясь фундаментальными усовершенствованиями процессов.
Есть простое средство измерения – ответ на вопрос: сколько критически важных процес-
сов или процессных шагов основано на динамических электронных таблицах? Это можно
назвать «индексом табличности». Многие организации не смогут эффективно функциониро-
вать, если у них отнять электронные таблицы. Если таблицы используются в управлении
процессами, у предприятия есть шанс утерять управление, поскольку каждый сотрудник со-
здает собственные версии механизмов «контроля». Если информация применяется в крити-
чески важных процессах, ее трудно использовать совместно и контролировать. Правильно
выбранные системы должны сделать излишним использование электронных таблиц.
Еще один показатель можно получить, если задуматься на минутку и честно ответить на
следующие вопросы:
1. вводят ли менеджеры с помощью небольших «сателлитных» баз данных новые элек-
тронные таблицы и решения в процессы и подразделения, которыми они управляют?
2. Сосредоточены ли менеджеры главным образом на краткосрочных тактических зада-
чах, а не на совершенствовании процессов на основе анализа коренных причин?
3. Измеряется ли качество посредством периодических выборок?
4. Нарастает ли (или, по крайней мере, не снижается) объем невыполненной в срок ра-
боты?
5. Нет ли у руководства и менеджеров точной меры для оценки объема переделанной
заново работы внутри организации и подразделений?
6. Имеется ли хоть какое-нибудь представление, во что обходится организации передел-
ка заново этой работы?
7. Есть ли у организации четкое знание фактических затрат на выполнение процесса или
транзакции?
8. Направлены ли показатели производительности персонала на измерение объема вы-
полненной работы?
9. Нацелены ли менеджеры в первую очередь на сокращение затрат?
10. Менее ли 80 % завершенных проектов реализовали преимущества, описанные в
технико-экономическом обосновании?
11. Сосредоточены ли процессы лишь на внутренних аспектах?
Если на любой из этих вопросов дается утвердительный ответ, то менеджеры организа-
ции не управляют ее бизнес-процессами. Разбираясь с подобными вопросами, организация
доберется до коренных причин процессных проблем и сделает первые шаги в направлении
программы непрерывного совершенствования бизнес-процессов.
Заключение
Управление на уровне организации в целом преимущественно занимается улучшением и
контролем процессов, неотъемлемых на предприятии для достижения его целей. Задание
общего направления и постановка задач совершенствования бизнес-процессов – критически
важный шаг, который нужно предпринять высшему руководству.
Хотя ввод технологий может быть полезным содействующим фактором во многих орга-
низациях, совершенствование не всегда требует технологии для успеха. Значительно важнее
отладить процессы до того, как думать о внедрении технологий автоматизации.
Наш опыт консультирования доказывает, что большинство усовершенствований в
краткосрочном плане можно получить, не прибегая к автоматизации.
Обязанностью исполнительного руководства организации является обеспечение четкой
связи между проектами совершенствования процессов, предпринятых организацией, ее стра-
тегией и целями. Если проект не дает строгого обоснования своего вклада в достижение це-
лей организации, и ее ценности, такой проект не следует реализовывать.

Глава 4. Когда следует браться за BPM; каковы основные движущие силы и меха-
низмы пуска?
Трудно ответить на эти вопросы в самой общей форме. Все зависит от конкретных об-
стоятельств: условий внутри организации, и ее процессной зрелости, а эти показатели могут
сильно меняться в зависимости от организации в целом и конкретной ситуации.
Некоторые из вероятных движущих сил и приводных механизмов, способных подтолк-
нуть организацию к рассмотрению возможности внедрения BPM, классифицированы в табл.
4.1 с точки зрения организации, управления, сотрудников, клиентов, поставщиков / партне-
ров, производимого продукта или оказываемых услуг, а также процессов и информационных
технологий. Разумеется, во многих случаях они пересекаются друг с другом.

Таблица 4.1. Факторы и механизмы, которые могут побудить организацию подумать о

внедрении BPM
Категория Движущие факторы и механизмы пуска
Организация  высокие темпы роста – трудно справляться с быстрым ростом или
 планировать с опережением в условиях быстрого развития
 слияния и поглощения вынуждают организации «прибегать» к до-
полнительным усложнениям или требуют рационализации процессов
 необходимость вывода из эксплуатации устаревших систем. Про-
ект ВМР позволяют «разместить» процессный слой по унаследованным
старым системам, давая время на разработку подходящей стратегии пре-
образования
 реорганизация – изменение ролей и распределения ответственно-
сти и обязанностей
 смена стратегии – решение сменить стратегическое направление
на совершенствование функционирования, обеспечение лидирующего
положения продукта или достижение доверительных отношений с клиен-
том
 не достигнуты цели или показатели организации – внедрение
управления процессами, увязанного со стратегией. Измерением и управ-
лением производительностью работы людей
 необходимость соответствовать законодательству и нормативным
актам и регулирование. Например, во многих организациях были иници-
ированы процессные проекты, чтобы удовлетворить требованиям закона
Сарбанеса – Оксли 2 . Затем эти проекты стали платформой для запуска
усовершенствования процессов или проектов внедрения ВМР
 необходимость обеспечить маневренность предприятий. Чтобы
они были способны реагировать на возникающие новые возможности
 необходимость более серьезно контролировать бизнес, полностью
управляя своей судьбой
управление  недостаток надежной управленческой информации или ее проти-
воречивость. Здесь может помочь управление процессами, а также изме-
рение и управление производительностью
 необходимость обеспечить менеджерам больший контроль про-
цессами в организации
 необходимость создания условий устойчивой производительности
 необходимость взращивания культуры высокой производительно-
сти
 необходимость достижения максимальной окупаемости суще-
ствующих «унаследованных» систем
 сокращение бюджетов
 умение получать б'ольшую выработку имеющегося персонала для
расширения деятельности
персонал  высокая текучесть кадров, возможно, вызванная скучным и утоми-
тельных характером работы, завышенными ожиданиями от персонала или
излишним давлением на сотрудников при отсутствии соответствующей
поддержки
 проблемы обучения новых сотрудников
 низкая степень удовлетворенности сотрудников
 вероятность существенного роста количества сотрудников
 желание расширить полномочия и усилить роль сотрудников
 сотрудникам трудно успевать за непрерывными изменениями и
нарастающей сложностью
Клиенты / по-  низкая степень удовлетворенности качеством сервиса, что может
ставщики / быть вызвано:
партнеры
2
Этот закон был принят Конгрессом США после серии скандалов и разоблачений махинаций в руководстве
крупных фирм, в первую очередь – энергетического гиганта, компании Enron, и телекоммуникационной ком-
пании Wordlcom, которые с помощью бухгалтерских уловок раздували прибыль и поддерживали высокую цену
акций. Закон ужесточает учет и отчетность, но вызывает дополнительные, иногда значительные, затраты на
соблюдение требований закона. – Прим. науч. ред.
  высокими темпами смены персонала
 неспособность персонала адекватно справляться с
задачами в установленные сроки
 непредвиденно быстрый рост количества клиентов, поставщиков
или партнеров
 затянутые сроки обработки ответов на заказы
 намерение организации сосредоточится на достижении довери-
тельных отношений с клиентом
 расслоение клиентов или многоуровневые сервисные требования
 внедрение и строгая реализации практики уровней сервиса
 крупные клиенты, поставщики или партнеры, которым требуется
уникальный (существенно отличающийся) процесс
 необходимость по-настоящему комплексного сквозного видения
организации, обеспечивающая прозрачность или интеграцию
Продукты и  затянувшийся срок выхода на рынок (недостаток маневренности
услуги предприятия)
 низкий уровень качества обслуживания заинтересованных сторон
 у каждого продукта или услуги имеются свои процессы, хотя
большинство процессов - общие или похожие
 новые продукты или услуги включают элементы существующих
продуктов / услуг
 продукты или услуги сложные. комплексные

Если действует несколько пусковых механизмов, важно провести анализ первопричин,

поскольку очень часто организации идут по пути наименьшего сопротивления и борются с
симптомами, вместо того чтобы при помощи фундаментальных и структурных мероприятий
справиться с причиной.
Среди факторов и пусковых механизмов, побуждающих организацию подумать о внед-
рении автоматизированного решения, можно назвать следующие:
• значительный объем похожих и повторяющихся комплексных операций-
транзакций;
• четкий поток трудоемких операций, переходящих от одного сотрудника к другому,
при этом каждый вносит свой вклад по пути прохождения операции;
• необходимость мониторинга операций в реальном времени (т. е. нужно знать со-
стояние операции в любой момент времени);
• длительность процесса обработка – критически важный вопрос, т. е. время играет
существенную роль;
• необходимость выполнения большого объема вычислений внутри комплексной
операции;
• доступ к операциям или «делам» должен быть обеспечен одновременно многим
участникам.
Тем не менее, нельзя автоматизировать процессы до такой степени, чтобы организация
не видела смысл в необходимости вовлечения персонала. Люди лучше всего справляются с
управлением взаимоотношениями, и их вовлечение в процесс должно быть правильно орга-
низовано.
В начале этой главы уже говорилось, что трудно определить момент, когда запускать
проект внедрения BPM. Любой организации следует начинать проект BPM, когда налицо
определенное количество и сочетание перечисленных выше побудительных мотивов и меха-
низмов пуска. Эти показатели разнятся как для каждой отдельной организации, так и для
каждой конкретной ситуации внутри одной организации.

Глава 5. Кто должен участвовать в BPM

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

Процессы – это не самоцель. Они – лишь средство достижения целей предприятия. Про-
цессы не обеспечивают достижение целей случайно или автоматически – необходимо посто-
янное и эффективное управление процессами.
Как уже говорилось выше, BPM есть управление и организация процессов, критически
важных для предприятия. На рис. 5.1 показано, как процессы поддерживают и содействуют
достижению стратегических, тактических и оперативных целей при помощи технологии и
людей. Процессы должны быть максимально эффективны и результативны. Этого можно
достичь периодическими проектами (ступенчатое совершенствование), а затем поддержи-
вать постоянным управлением и измерениями.
Управление бизнес-процессами
Можно предложить два аспекта операционного управления бизнес-процессами:
1. как составная часть «управления» в целом.
2. Управление совершенствованием бизнес-процессов.
1. BPM как составная часть «управления» в целом
Данный тип управления должен обеспечить реализацию целей бизнеса и стратегии ор-
ганизации. Такое управление осуществляется линейным руководством (или хозяевами биз-
нес-процессов), и его нельзя поручить внутренним или внешним консультантам BPM, по-
скольку эта роль обычно является неотъемлемой составной частью общего управления.
Например, руководство верхнего звена должно отвечать за процессы от начала до конца, а
руководители среднего звена – за отдельные их составляющие. Ключевой характеристикой
линейных руководителей является то, что они – хозяева процессов. Перечислим типичные
обязанности, связанные с владением процессами:
• определение целей (задач) и показателей, которые увязаны с целями и норматива-
ми – эти нормативы нужно разбить на ежедневно или еженедельно измеряемые показатели
для постоянного мониторинга и управления;
• доведение целей, показателей и нормативов до исполнителей процессов, при необ-
ходимости обеспечивая вознаграждения и стимулирование;
• мониторинг и управление комплексом нормативов; необходимо убедиться, что це-
ли и показатели остаются точными и значимыми;
• мотивирование персонала для превышения им целевых нормативов и работы по
устранению нарушений в процессах;
• поощрение персонала на выявление «узких мест» и возможных улучшений процес-
сов.
Можно выделить три категории таких линейных руководителей по их основной сфере
деятельности:
• оперативные (операционные) менеджеры работают с четко определенными процес-
сами и увязанными целевыми показателями - перераспределение человеческих ресурсов
(например, выделение большего или меньшего количества сотрудников), а также в решение
операционных проблем (например, исправление ошибок в результате процессов);
• тактические менеджеры - совершенствование процессов;
• стратегические менеджеры работают с бизнес-моделью и связанными с ней про-
цессами.
2. Управление совершенствованием бизнес-процессов
Управление совершенствованием бизнес-процессов связано с определением, разработ-
кой и реализацией преимуществ BPM. В данном случае менеджеры, ответственные за дан-
ный процесс, оказывают поддержку менеджерам бизнеса/организации в усовершенствова-
нии их процессов и не должны отвечать за повседневное управление бизнес-процессами. Та-
ких менеджеров мы называем менеджерами BPM и различаем следующие категории:
• менеджер проекта BPM. Основная обязанность – обеспечить достижение целей
проекта BPM, сформулированных в его обосновании;
• менеджер программы BPM. Основная обязанность – содействовать нескольким
проектам BPM, чтобы обеспечить достижение целей программы, и сделать это максимально
эффективным и продуктивным способом, распространяя лучшие образцы и опыт и извлекая
уроки;
• менеджер Центра совершенствования бизнес-процессов. Главная обязанность –
обеспечить согласованность бизнеса и бизнес-процессов, чтобы извлечь максимум пользы и
преимуществ из последних;
• главный руководитель процессов (СРО). Сфера ответственности – выстраивание
процессов и ИТ в соответствии со стратегией, бизнесом и организацией, чтобы эта деятель-
ность постоянно управлялась на уровне исполнительных органов организации.
Ближе к бизнесу
Все менеджеры BPM должны осознавать, что их роль – способствовать достижению це-
левых показателей, поставленных линейными руководителями/хозяевами процессов, а не
строить империю. В идеале, сотрудники, работающие с менеджерами BPM или подчиняю-
щиеся им, должны быть взяты из подразделений предприятия, вовлеченных в проект, по-
скольку они дадут возможность быть ближе «к земле», чего него нельзя ожидать от сотруд-
ников центральных подразделений, не связанных непосредственно с бизнесом. Крупные
центральные службы не обладают близостью к бизнесу. Главная причина состоит в том, что
планировать процессы на бумаге – это просто, но быть способным постоянно осуществлять
их в изменяющихся условиях – настоящий вызов, который еще долго остается таковым уже
после завершения самого проекта.
Нужно помнить, что самый важный критерий успеха – не изящество моделей или реше-
ний, а также не самые замысловатые инструменты моделирования и управления процессам.
Главнейший критерий успеха – реальное использование организацией решений BPM и до-
стижение или даже превышение заявленных результатов.
В среднем около 80 % времени линейного руководителя должно уходить на обычную
повседневную работу (например, анализ результатов), обучение и решение проблем, и толь-
ко 20 % следует отдавать разработке новых процессов или инициатив бизнеса. Наоборот,
менеджеры BPM более 80 % времени будут тратить на работу по совершенствованию про-
цессов. (Заметим, что данные процентные доли могут меняться в зависимости от времени и
ситуации, а также других факторов: личности менеджера, обычной повседневной нагрузки и
т. п.)
Это различие в направленности между двумя типами управленцев дает основание для
натянутости отношений между линейными менеджерами и менеджерами BPM. Линейный
менеджер сосредоточен на достижении краткосрочных целей, и любое изменение может по-
влиять на его способность выполнять свои обязанности в срок. Менеджер BPM фокусирует-
ся на изменениях, оптимальных для достижения долгосрочных целей. Успешные менеджеры
смогут найти решение, выигрышное для обоих типов.
Привлечение внешних специалистов по BPM
В силу самой природы управления людьми и процессами в долгосрочном плане реко-
мендуется, чтобы персонал из самой организации всегда выполнял функции, описанные вы-
ше, чтобы обеспечить внутреннее принятие проекта и преемственность. Но на начальных
этапах освоения BPM и реализации нескольких первых проектов целесообразно назначить
специалистов и менеджеров проектов BPM извне, чтобы содействовать передаче знаний и
опыта BPM сотрудникам организации.
После реализации первых проектов внешняя поддержка менеджеров может переклю-
читься на другой комплекс обязанностей, например:
• организацию проекта, программы или Центра совершенствования бизнес-процессов.
Внешние консультанты могут передавать накопленный во многих организациях опыт и осу-
ществлять общее руководство. Это особенно полезно, если организация желает, чтобы ее це-
ли не были слишком амбициозными или слишком скромными (хотя последнее все же пред-
почтительнее). Работу нужно начинать прагматично (мыслить ГЛОБАЛЬНО, начинать с ма-
лого). Отсутствие амбиций ведет к невозможности фундаментальных перемен, тогда как от-
сутствие прагматичности подхода – к невозможности соответствовать ожиданиям или раз-
вивать первоначально вложенные усилия;
• мониторинг продвижения проекта, программы, Центра совершенствования бизнес-
процессов. Внешние консультанты независимы и способны ставить жесткие вопросы. Часто
люди поглощены деталями моделей процессов и структуры проекта, программы или Центра
совершенствования бизнес-процессов, что может привести к потере видения главной цели;
• мониторинг работы предприятия и определение сфер усовершенствования. Внеш-
ний консультант может периодически проводить анализ работы конкретного подразделения
и его персонала. При необходимости результаты такого анализа обсуждаются с линейным
менеджером для принятия мер по исправлению недостатков;
• разрешение конфликтов и оздоровление проектов/программ. Внешний консультант
может помочь организации, если исходный проект/программа или Центр совершенствования
бизнес-процессов не дает ожидаемых результатов. Первоочередная задача внешнего кон-
сультанта – выявить главные проблемы и определить, можно ли все еще добиться изначаль-
но поставленных целей и что необходимо предпринять. Внешний консультант может сыг-
рать роль ледокола;
• поддержку менеджерам. Внешний консультант может помочь менеджеру BPM в
случае перегрузки рабочими функциями, что особенно характерно во время крупных органи-
зационных перемен. Внешний консультант становится правой рукой/советником менеджера
BPM. Менеджер BPM должен по-прежнему оставаться ответственным за принятие решений
и работу с заинтересованными сторонами, а консультант оказывает помощь в анализе и
надзоре за различной деятельностью в сфере ответственности менеджера BPM;
• оценку (или аудит) проектов и программ. По завершении проекта или программы
оценка результатов имеет принципиальное значение и может помочь в извлечении уроков
для реализации последующих замыслов, а также при оценке и определении нерешенных
ключевых проблем в рамках проектов. В таких условиях внешний консультант может задать
каверзные вопросы, ключевые для осознания ошибок.
Проекты BPM могут оказаться чрезвычайно сложными, и налицо тенденция обеспечи-
вать внутренним менеджерам бизнес-проектов и менеджерам BPM помощь со стороны
наставника BPM. Эту роль обычно выполняет консультант BPM высокого уровня (внешний
или изнутри организации), который на регулярной основе (один-два раза в месяц) наставляет
менеджера BPM / менеджера проекта на путь решения основных проблем. Это может ока-
заться полезным и для линейных менеджеров, стремящихся внедрить процессное мышление
сотрудникам с целью добиться постоянных улучшений. В большинстве случаев такое
наставничество начинается с практического семинара или проекта, за которым следуют по-
стоянные обучающие тренинги.

Глава 6. Почему для управления бизнес-процессами важны стратегия организации

и архитектура процессов
Первый вопрос, который предприятие должно поставить в начале любого проекта BPM,
– это вопрос о цели и задачах процессов. Ответ часто бывает уклончивым – да, пока эти ха-
рактеристики не сформулированы, но нельзя ли начать с анализа и усовершенствования про-
цессов? Такой подход в управлении процессами абсолютно порочен. Но даже когда в орга-
низации это понимают, все равно используют подобный подход просто ради получения
быстрого выигрыша и лежащих на поверхности результатов.
Почему стратегия организации важна для бизнес-процессов?!
 Иногда стратегия организации не принимается во внимание в бизнес-процессах. Ниже
приводятся причины такого положения и обсуждаются выводы, к которым мы пришли по
результатам собственных исследований и накопленного опыта:
1. нет специально сформулированной стратегии. В большинстве случаев имеется
неявно обозначенная стратегия организации или предприятия, при этом в принципе возмо-
жен конфликт с какими-либо явными формулировками. Другой подход к этой проблеме –
рассмотрение целей организации и того, как она предполагает реализовать или достичь их.
Чтобы обеспечить эффективный и продуктивный вклад бизнес-процессов в стратегию
организации, необходимо иметь конкретную и четкую формулировку целей и стратегии. Не
имея согласованных заранее целей и задач, невозможно усовершенствовать процессы, чтобы
они добавляли ценность и вносили вклад в цели и стратегию организации. Откуда группа
проекта знает, что она движется в правильном направлении? Лучшее, что можно сделать в
такой ситуации, – это отложить реализацию проекта (проектов), усовершенствующего про-
цессы, пока не выбраны цели и стратегия.
2. Получение информации о стратегии отнимает слишком много времени. В этом
случае информация либо плохо доводится до сотрудников, либо разбросана по подразделе-
ниям. Важно в самом начале посвятить достаточно времени пониманию и получению этой
информации, а не браться сразу за анализ процессов, а в конце обнаружить, что исходные
посылки были неверными. В данном случае можно использовать совещания с основными
заинтересованными сторонами для получения стратегической информации и пропаганды
ожидаемых выгод проекта.
3. Персонал, привлеченный к проекту, не способен мыслить стратегически. Суще-
ствует мнение, что операционный персонал не должны беспокоить или даже запутывать
стратегические вопросы, поскольку он должен сосредоточиться на вопросах операционных.
Однако это не так, поскольку для операционного персонала и менеджеров очень важно
понимать стратегический выбор целей и его последствия. Если понимания не существует,
практические семинары оказываются полезным механизмом доведения данной информации
до привлеченного в проект персонала, показывая, как вопросы стратегии влияют на работу, и
как персонал может способствовать успеху стратегии. Персонал, непосредственно участву-
ющий в операционной деятельности, начинает ставить операционные проблемы, которые, по
его мнению, не согласуются со стратегическим направлением. Если операционные менедже-
ры и персонал не осознают стратегического направления и не готовы ему, обеспечить эф-
фективное и успешное функционирование предприятия весьма проблематично.
4. У нас уже выработан перечень пожеланий, и нам не нужно вникать в страте-
гию.
Многие проекты начинаются с заранее сформулированного списка «пожеланий» в части
совершенствования. Большинство этих пожеланий относится к повседневной работе и при-
нимает имеющиеся процессы и рабочую среду как данное.
Часто наибольший эффект достигается, лишь когда анализ учитывает стратегические со-
ображения. Это позволяет поставить под вопрос и сомнение некоторые закостеневшие и
молчаливо принимаемые предположения и ограничения. Пожелания часто фокусируются
лишь на операционных требованиях и рассчитываются на короткий срок, тогда как перед
большинством организаций стоят проблемы фундаментальных перемен, которые значимо
действуют именно на стратегическом уровне.
Что должна содержать стратегия организации и архитектура процессов, чтобы со-
здать подходящие условия для анализа и совершенствования процессов?!
Иногда анализ или обсуждение путей совершенствования процессов неоправданно затя-
гиваются, потому что у сотрудников одной и той же организации не всегда есть общая пози-
ция, так как информация принимается по умолчанию. Если у всех участников проекта сфор-
мирована общая исходная позиция, то большинство относящихся к процессам вопросов
можно решить практически мгновенно, в отличие от традиционных методов прихода к еди-
ному мнению. Если нет четкого структурирования, все вопросы (т.е. целевые показатели,
стратегия, ограничения, принципы и руководящие инструкции) будут перемешаны. Четко
сформулированные условия рабочей среды позволяют рассматривать каждый новый аргу-
мент в рамках согласованного контекста и определять влияние этого аргумента на процессы.
Как минимум, необходимо учитывать целевые показатели организации (хороший ин-
струмент для измерения – таблицы сбалансированных показателей), стратегический выбор
(доверительные отношения с клиентом, совершенство функционирования или ведущее по-
ложение продукта), модель бизнеса (взаимоотношения с клиентами, партнерами, конкурен-
тами и сообществом в целом), а также основные направляющие принципы организации (в
том числе ценности организации). Помимо этого должны быть конкретные принципы, осо-
бые для процессов. Все перечисленные выше элементы мы в совокупности назовем «архи-
тектурой процессов».
Архитектура процессов обеспечивает определенность всей базовой информации, состо-
ящей из основы и руководящих инструкций для рассмотрения и совершенствования процес-
сов, и может быть использована как опорный документ. По ней можно легко установить
влияние любого внутреннего или внешнего изменения.
Архитектура процессов
Почему архитектура процессов иногда не применяется? Наши исследования выявили,
что в качестве причин часто приводятся следующие утверждения:
1. у нас уже есть модели процессов. Часто смешивают модели и архитектуру про-
цессов. Нам приходилось встречаться с людьми, которые с гордостью показывали свои тща-
тельно проработанные модели процессов, напечатанные в цвете на постерах. Однако такие
люди скромно молчали, когда их спрашивали, когда эти модели обновлялись последний раз,
как они сопровождаются и поддерживаются.
Архитектура процессов значительно больше, чем модели процессов. Она включает целе-
вые показатели, стратегию и руководящие (направляющие) инструкции, которые являются
основой для моделей. Модели процессов – всего лишь мгновенный срез существующего на
данный момент мышления и восприятия. Они не дают четкого руководства для анализа су-
ществующих или создания новых процессов. Фактически, процесс, который переживает ор-
ганизация во время создания согласованной архитектуры, даже более важен, чем сама доку-
ментально оформленная в конечном итоге архитектура. Именно в процессе ее создания при-
нимаются важнейшие решения, а предприятие приобретает понимание и осознание важности
архитектуры.
2. Усилия по созданию архитектуры процессов стоят больше, чем получаемые от
этого выгоды. Если руководство и предприятие в целом скептически относятся к необходи-
мости иметь архитектуру процессов, это обычно говорит о том, что они не понимают важно-
сти установленных правил и направляющих инструкций для моделей и структуры процес-
сов. Возможно, руководство не участвовало в практических семинарах и процессе принятия
решений, когда создавалась архитектура процессов.
При использовании правильно сформированной архитектуры процессов экономится
больше времени и усилий, чем при ее отсутствии. Более того, архитектура процессов дает
средство коммуникации, определения и согласования принципов и целей процессов, так что
это становится понятным для всех. Если же архитектура процессов уже выработана, значи-
тельно проще определить степень воздействия предлагаемых изменений по сравнению с со-
гласованным стандартом.
3. У нас есть архитектура процессов, но ею никто не пользуется. Многие создатели
архитектуры процессов настолько увлекаются самим процессом ее создания, что делают ар-
хитектуру значительно сложнее, чем нужно, забывая, что необходимость и успех архитекту-
ры измеряются степенью ее использования и выгодами, которые она обеспечивает организа-
ции.
Распространенная ошибка создателей архитектуры состоит в том, что если руководство
и бизнес не участвуют в разработке архитектуры процессов, появляется опасность, что архи-
тектура станет излишне усложненной. В данном случае первостепенная задача – привлече-
ние всех заинтересованных сторон, чтобы добиться их согласия, соучастия и использования.
Наиболее успешные архитектуры (реально используемые для поддержки принятия решений)
относительно сжаты и просты.
4. Мы договорились об общей архитектуре процессов, но никто ее не придержива-
ется. Общая архитектура процессов согласована, но не успели высохнуть чернила, как уже
появилось множество факторов, провоцирующих отклонения от нее – новое законодатель-
ство, новые продукты, запросы клиентов и т. п. Поначалу архитектура процессов успешно
справляется с подавлением этих факторов, но выстоять под давлением руководства и бизне-
са ей не удается. Как только появляется первое исключение, их число начинает расти с обес-
кураживающей скоростью, и архитектура процессов мгновенно становится бесполезной. Чем
дальше проекты уходят от архитектуры процессов, тем выше их риск.
Необходимо осознать, что иногда отклонения от согласованной архитектуры процессов
необходимы. Поэтому архитектура должна адаптироваться к потребностям бизнеса, т.е. быть
динамичной, а не статичной, как было в прошлом. Поэтому вместо устранения исключений,
лучше целенаправленно управлять ими, т.е. убедиться, что для исключения есть реальная
причина и оно ограничено (остается в некоторых пределах согласованной архитектуры про-
цессов), и обеспечить принятие мер для согласования исключения с архитектурой процессов
и соответствия ей.

Глава 7 Как убедить организацию принять технологию управления бизнес-

процессами
Фритц Буссемейкер (Frits Bussemaker)

Хотя многие практики BPM внутри организации открыли для предприятия существен-
ные преимущества в использовании решений автоматизации бизнес-процессов, этим прак-
тикам часто приходится сильно потрудиться, чтобы убедить остальных сотрудников,
особенно должностных лиц, ответственных за принятие решений и распределение бюдже-
та, в необходимости финансирования.
Фриц Буссемейкер, председатель Форума BPM в Голландии, описывает, каким образом
следует позиционировать и представлять решение автоматизации управления бизнес-
процессами, чтобы оно получило признание. Главный посыл состоит в том, что есть много
заинтересованных сторон, и важно сосредоточиться на выгодах для предприятия, а не на
технологии.
Бизнес-процессы окружают нас повсюду, независимо от рынка, организации, подразде-
ления или функции — будь то:
 оператор связи, обеспечивающий подключение по ADSL своему абоненту,
 банк, обрабатывающий заявление о предоставлении кредита,
 страховая фирма, рассматривающая требование о выплате страховки, или даже
 местный орган внутренних дел, принимающий заявление о выдаче нового паспорта.
Можно утверждать, что любая организация - это совокупность бизнес-процессов. По
крайней мере, бизнес-процесс следует рассматривать как фундаментальный элемент инфра-
структуры любой организации. Во всех рассмотренных выше примерах объем работ и слож-
ность бизнес-процесса требовали от организации поиска возможных приложений ИТ для
поддержки и автоматизации процессов. Годами многие компании вкладывали миллионы во
всевозможные решения ИТ:
 у подразделений маркетинга есть системы управления контентом предприятия (ECM)
для информирования потребителя о продуктах или услугах, предлагаемых организацией;
 подразделения продаж используют систему управления взаимоотношениями с клиен-
тами (CRM), позволяющую осуществлять кросс-продажи (продажи сопутствующих товаров)
и расширенные продажи (продажи более сложных и дорогих товаров — upselling);
 в отделах доставки существует система планирования ресурсов предприятия (ERP)
для обработки заказов и направления счетов.
Реальность в большинстве организаций сегодня такова, что эти подразделения работают
как самостоятельные беспорядочные «муравейники» (рис. 7.1).
Правление

Маркетинг Продажи Доставка

ECM CRM CRP

 Клиент-потребитель

Рис. 7.1. Автоматизация функциональной мешанины (беспорядок)

Клиенты:
 часто сталкиваются с негодным обслуживанием из-за разрывов в процессах, их неэф-
фективности и выполняемых вручную процессов, т.е. с неупорядоченной массой различных
систем в организации;
 становятся все более требовательными к срокам доставки: если раньше они были
привычны и смирялись с доставкой через несколько дней, а то и недель, то в последние годы
стали привыкать к не имевшим ранее оснований ожиданиям более коротких сроков в реаль-
ном времени;
 требуют более высокого качества продуктов или услуг.
Наконец, продукты и услуги становятся все более персонализированными (и, значит, бо-
лее сложными) и поддерживаются расширенным клиентским сервисом: «Вот что мне нужно,
и мне это нужно сейчас».
Каким образом организация может ответить на эти растущие требования в условиях, ко-
гда одновременно:
 увеличивается количество точек соприкосновения с клиентом (например, телефон,
факс, электронная почта, СМС, персональные цифровые ассистенты и т.д.);
 варианты продуктов, сервиса и цен повышают сложность бизнеса;
 у большинства организаций есть целый набор систем типа «сформируй и купи» и
приложений с индивидуальным форматом данных;
 бюджеты урезаются.
Организации должны осознать, что все их активы, системы, подразделения и персонал
взаимосвязаны. Есть множество внутренних процессов, образующих «цепочку поставок» и
связанных со сквозным процессом организации. Вообще говоря, предпочтительно иметь од-
ну (а указаны три – С.К.) точку соприкосновения с организацией:
1. маркетинг — какой продукт или услуга предлагается;
2. продажи — просьба работать со мной как с одним единым клиентом;
3. доставка — предоставьте продукт или услугу как можно быстрее.
Ключевой элемент принятия BPM в организации — осознание того, что организация
может рассматриваться как сумма ее бизнес-процессов. Другими словами, автоматизация
управления бизнес-процессами — это не только внедрение технологии автоматизации, но и
автоматизация в правильных обстоятельствах. Существующие приложения можно связать
друг с другом на самостоятельном процессном слое. Автоматизация BPM также означает
новый способ работы, мониторинга и управления организацией, что может привести к новой
организационной структуре.
Как упрощенно показано на рис. 7.2, технология управления бизнес-процессами может
дополнять существующие (и будущие) вложения приложениями. BPM:
 обеспечивает отдельный независимый процессный слой, связывающий различные са-
мостоятельные приложения, необходимые для выполнения единого сквозного бизнес-
процесса;
 дает возможность контролировать поток операций по различным приложениям и
участвующий в нем персонал;
 способна сократить время исполнения;
 дает возможность организации вести мониторинг эффективности и одновременно
проверять соблюдение установленных правил.
Анализ данной информации также поможет и далее совершенствовать бизнес-процессы.
Все эти действия могут выполняться в режиме реального времени: руководство может вно-
сить мгновенные изменения и проверять, достигают ли они желаемого эффекта.
 Правление

Маркетинг Продажи Доставка

Клиент-
потребитель

ECM CRM CRP

Рисунок 7.2. Сквозной процесс работы с клиентом рассекает функциональную мешани-

ну

Поскольку бизнес-процесс может охватывать персонал из разных подразделений, орга-

низациям следует подумать, как распределить ответственность, назначить хозяев и менедже-
ров процессов, измерить их эффективность и результативность. Это также означает, что в
большинстве организаций должны привлекаться как бизнес-подразделения, так и ИТ-
подразделения. Опыт показывает, что организации, успешно использующие технологию
процессов, начинают с решения конкретной проблемы предприятия с четкой окупаемостью
вложений (ROI). Таким образом, все, кто продвигает управление бизнес-процессами как из-
нутри, так и извне организации, должны учитывать обе части равенства:
Управление бизнес-процессами = процесс и организация (включая персонал), а также
технология.
В конце концов, речь идет о продвижении парадигмы бизнеса: внедрение технологии
управления бизнес-процессами может содействовать процессно-центрированному становле-
нию организации.
Может ли технология управления бизнес-процессами сформировать более эффективную
организацию с меньшими расходами? Конечно! Только посмотрите на устаревшую структу-
ру неупорядоченных разрозненных систем, где различные подразделения тратят уйму вре-
мени, средств и усилий, которые не всегда связаны, так что усилия различных подразделе-
ний часто фактически противоречат друг другу. Управление бизнес-процессами может по-
мочь увязать усилия отдельных подразделений. Тогда результирующий итоговый вектор
увеличится (рис. 7.3).

Кому нужна технология управления бизнес-процессами

Выше уже отмечалось, что в принятие технологии вовлечены как бизнес-, так и ИТ-
подразделения. Поскольку процессы присутствуют везде, это также подразумевает, что лю-
бой бизнес-менеджер может увлечься автоматизацией управления бизнес-процессами. При-
ведем общие аргументы в пользу принятия этого решения бизнес-менеджером:
 технологии управления бизнес-процессами обеспечивают их прозрачность;
 предприятие становится более маневренным;
 производительность повышается с меньшими расходами;
 можно обеспечить соблюдение нормативных правил;
 улучшается обслуживание клиентов.
Эти аргументы следует представить в виде конкретных бизнес-преимуществ, средством
достижения которых является BPM.
В направлении подразделения ИТ следует сделать акцент на следующих моментах:
 при технологии BPM не окажутся бесполезными предшествующие вложения средств
в приложения ИТ;
 управление бизнес-процессами свяжет вместе эти самостоятельные приложения;
 подразделение ИТ может быть более восприимчиво к меняющимся требованиям биз-
неса;
 новые приложения можно получать быстрее, дешевле и с большей гибкостью;
 управление бизнес-процессами также является ключевым элементом сервисно-
ориентированной архитектуры (СОА – SOA - Service-oriented architecture).
И, наконец, важно не забыть о вовлечении высокопоставленных исполнительных долж-
ностных лиц организации. Как уже подчеркивалось выше, управление бизнес-процессами и
связанная с ним технология, весьма вероятно, изменит способы управления предприятием и
даже его структуру. Поэтому поддержка высшего руководства необходима.
Кто продвигает технологию управления бизнес-процессами
Можно назвать следующие три силы, продвигающие решение автоматизации управле-
ния бизнес-процессами:
1. силы внутри предприятия.
2. Поставщик программного обеспечения.
3. Системный интегратор и/или консультант.
Во многих организациях есть внутренние спонсоры и сторонники решения автоматиза-
ции BPM. Однако наблюдается переход от усилий индивидов - энтузиастов к более структу-
рированной поддержке хозяев процессов, Центров совершенствования бизнес-процессов или
главных руководителей процессов. Во многих случаях собственный персонал организации
успешно использует опыт и уроки, полученные во время предыдущих проектов.
Долгое время поставщики решений BPM были нишевыми игроками на узком рынке. По-
ставщики ПО для «чистых» решений BPM начинали с разработки и поставки решений для
рабочего процесса (например, Staffware) или управления документацией (например, Filenet).
Когда первые специалисты — энтузиасты внедрения технологий BPM продемонстрировали
их существенные выгоды и преимущества для предприятий, а также хорошую окупаемость
(высокий коэффициент ROI), такие бизнес-аналитики, как Гартнер (Gartner) и Форрестер
(Forrester) начали обращать на это внимание. О перспективах и преимуществах управления
бизнес-процессами были написаны благоприятные отчеты, а также спрогнозирован рынок
объемом в миллиард долларов США. Это, естественно, пробудило рынок поставщиков ПО.
Появились новые игроки — поставщики «чистых» решений, а некоторые изменили позици-
онирование, подавая себя не в качестве поставщиков CRM, а в качестве поставщиков систем
BPM. Третья категория игроков вышла на рынок путем приобретения или поглощения
(например, Tibco software, купившая компанию Staffware). Наконец, такие традиционные
крупные фирмы, как IBM, SAP и Siebel, стали предлагать решения типа BPM. Однако, как
описано в данной главе, решающим фактором все еще является то, что поставщики ПО рас-
сматривают управление бизнес-процессами с точки зрения конкретного бизнеса, а не с точки
зрения пакетного решения.
В то же время многочисленные системные интеграторы вкладываются в знания BPM и
организуют специализированную практическую деятельность по ним. Консультационные
фирмы предлагают услуги проектирования, описания и содействия внедрению бизнес-
процессов. Важно убедиться, что эти организации способны обеспечить лучшее решение, и
не ограничены узкими рамками в силу партнерства или владения конкретным пакетом реше-
ния.
 Для разработки стандартов BPM созданы такие ассоциации, как WfMC и BPMI.org.
Сформированы сообщества BPM, например, bpm-forum.org и BPtrends.com. Доступны мно-
гочисленные новые веб-сайты, курсы обучения, специализированные журналы и ученые
степени.
Имея столь многообразные источники решений: от поставщиков «чистого» ПО BPM и
консультационных фирм до диссертаций на соискание ученых степеней, при выборе кон-
кретного поставщика покупатель должен очень четко представлять себе бизнес-требования
организации и учитывать, что резкий рост количества поставщиков решений BPM рано или
поздно приведет к консолидации рынка и уходу с него мелких компаний.

Глава 8 Каковы решающие факторы успеха проекта BPM?

Как уже отмечалось выше, реальность внедрения BPM значительно сложнее, чем кажет-
ся на первый взгляд. Проекты BPM потенциально (а так обычно и происходит) пересекают
границы подразделений и все чаще выходят за рамки организаций, вовлекая больше клиен-
тов, поставщиков решений и партнеров. Проекты затрагивают множество меняющихся и
сложных взаимоотношений между заинтересованными сторонами как внутри, так и вовне
организации.
Хотя каждый отдельный проект уникален и имеет свои индивидуальные характерные
факторы успеха, мы выделили десять базовых критически важных факторов для успеха всех
проектов BPM:
1. Лидерство/ведущая роль. Очень много написано о ведущей роли в связи с BPM. Вы-
сказывалось предположение, что если не удалось заручиться безраздельной и полной под-
держкой высшего исполнительного лица (руководителя) организации (СЕО), не следует за-
тевать никакие проекты BPM. На практике же лишь немногие руководители компаний гото-
вы сделать из руководимых организаций полностью процессно-сконцентрированные пред-
приятия. Хотя, несомненно, растет понимание важности процессов для организаций, впереди
еще долгий путь. Как подробнее говорится ниже, руководство не всегда означает именно
высшего руководителя. Внутри организации могут оказаться лидеры, экспериментирующие
с проектами BPM. Лидерство в этом контексте означает внимание, поддержку, финансиро-
вание, твердую приверженность и время руководителя, участвующего в проекте. Очевидно,
что мера каждого из этих качеств меняется в зависимости от зрелости организации и руково-
дителя по отношению к BPM. На них также влияет тип реализуемого проекта BPM: от опыт-
ных пилотных проектов и «экспериментальных» внедрений до полномасштабных реализа-
ций в рамках отделений или всего предприятия. Время - особенно важный фактор для проек-
та. Это не означает, что руководитель появляется на совещаниях руководящего комитета
один раз в месяц. Обязательство уделять время учитывает еще и поддержку проекта в среде
коллег, заинтересованных сторон, клиентов, поставщиков и сотрудников внутри организа-
ции. Руководитель — это «главный проводник» BPM, и ему нужно постоянно пропаганди-
ровать предполагаемые выгоды и преимущества, быть рупором и наглядным примером ре-
альности BPM.
2. Опытный бизнес-менеджер проекта BPM. В определенном смысле эта роль на сту-
пеньку ниже ведущей роли руководителя. Менеджер возглавляет группу проекта, весь окру-
жающий персонал, заинтересованных лиц и всю деятельность. Он обязан обладать значи-
тельными навыками работы с заинтересованными сторонами, а также необходимым образом
влиять на отношение персонала к проекту. Хотя можно утверждать, что для грамотного про-
ектного управления эти навыки необходимы всегда, проекты BPM требуют более полной и
точной их реализации. Другой немаловажный аспект данного фактора успеха — необходи-
мость, чтобы менеджер проекта был из бизнес-подразделения, а не из подразделения ИТ.
Проект BPM — это бизнес-проект, влияющий на результаты бизнеса, а составляющая ИТ
может либо вовсе отсутствовать, либо являться лишь частью проекта. Более того, проект
BPM требует фундаментальных и структурных перемен, чего часто нет в «традиционных»
проектах (это станет очевидным в части II).
3. Увязка со стратегией организации. Проекты создаются, чтобы вносить дополнитель-
ный вклад в осуществление стратегии организации, и ее цели. В противном случае проект не
нужен, если он заранее не планировался как краткосрочное тактическое решение; такие ре-
шения, однако, могут оказаться чрезвычайно опасными. Сколько раз нам приходилось стал-
киваться с краткосрочными тактическим решениями лет через двадцать после их реализа-
ции, которые настолько плотно были вплетены в саму ткань организации, что заменить их
было практически невозможно. Нет ничего более постоянного, чем временные решения. Ме-
неджеры прибегают к временным решениям, чтобы решить неотложную проблему, но затем
внимание отвлекается на другие вопросы, и у них так и не находится времени, чтобы вер-
нуться к исходной проблеме, а это приводит к череде тактических временных решений, ко-
торые становятся серьезным операционным вызовом. Стратегия организации — это основа,
которая объединяет всех участников проектов и обеспечивает их работу на общие цели.
4. Архитектура процессов. Если организация приняла BPM в качестве стратегического
направления, внедрила или реализует несколько проектов BPM, то для обеспечения макси-
мальных выгод чрезвычайно важен «синергетический» подход и согласованность внутри ор-
ганизации. Нужно иметь комплекс согласованных руководящих инструкций и проектных
руководств, в противном случае различные части организации будут тянуть в разные сторо-
ны, и единого подхода не получится. Архитектура процессов — не просто набор их краси-
вых моделей; она описывает основополагающие принципы процессов (или BPM) внутри ор-
ганизации и является основой любых изменений в подходе организации к BPM.
5. Структурированный подход к внедрению BPM. Без согласованного структурирован-
ного и системного подхода к реализации проектов BPM, который учитывает стратегию орга-
низации, принципы ее осуществления и поведенческие аспекты внедрения, проект остается
хаотичным, и ему свойственны очень высокие риски. Слишком часто проекты BPM испол-
няются на основе традиционного проектного управления или «здравого смысла». По мере
развертывания проекта и нарастания требований реальных результатов «интуитивные» шаги
теряют необходимую структурированность и системность подхода. В общей схеме, описан-
ной в данной книге, такой подход заложен.
6. Работа с персоналом, позволяющая необходимым образом влиять на отношение со-
трудников к проекту. Процессы исполняются либо самими людьми, либо людьми, воору-
женными технологиями. Люди могут обеспечить успех проекта BPM либо обречь его на не-
удачу. Если сотрудники не восприняли проект сердцем и не поддерживают его, велики шан-
сы на неудачу. Работа, направленная на позитивное изменение отношения сотрудников к пе-
ременам, может отнимать от 25 до 35% времени и сил. Как часто приходится слышать, что
«люди — наше главное достояние»! Однако организации тратят менее 1% бюджета проектов
на аспекты, связанные с человеческим капиталом. Этого просто недостаточно для любого
проекта, а при растущем воздействии процессов на людей доля должна быть значительно
увеличена. Необходимо, чтобы группа проекта тратила существенную часть времени и сил
на изменения в людях. Человеческий аспект любого изменения процессов и процессной ра-
боты должен адекватно и благожелательно оцениваться и приниматься.
7. Персонал и наделение расширенными полномочиями. Выше (см. п. 6) подчеркивалось,
что проекты BPM оказывают огромное влияние на людей. Вполне возможно, что роли пер-
сонала кардинально изменятся в связи с изменением задач и действий сотрудников. Воз-
можно, их производительность будет измеряться и контролироваться. Главам бизнес-
коллективов, может быть, впервые придется реально «управлять» процессами, объемами ра-
бот и планами ресурсов. Этим руководителям и персоналу понадобится поддержка, и не
только в виде обычного обучения, но и путем «натаскивания» по методу «один на один» и
подсказок-рекомендаций. Главы коллективов, как и менеджеры, часто выступают в роли
«пожарных», и тогда у них совсем мало времени на работу по процессам и «натаскивание»
персонала. Люди — это действительно главный капитал организаций, и нельзя оценивать
их производительность, пока не изменены процессы (системы) и структура для поддержки
проекта BPM. Когда процессы, роли персонала, структура и измерения производительности
сотрудников, а также обратные связи перепланированы и реализованы, персонал должен по-
лучить доверие и полномочия выполнять работу. Необходимо обеспечить сотрудникам
условия для работы, которые позволят раскрыться их творческому потенциалу и гибкости
при выполнении своих функций. Это возможно при четком определении роли персонала, а
также постановке конкретных и понятных для сотрудников задач и нормативов.
8. Инициирование и завершение проекта. Все инициативы BPM в организации должны
быть согласованы друг с другом, а после их завершения необходимо проводить постпроект-
ный анализ, чтобы гарантировать учет уроков, усвоенных в данном проекте, при реализации
последующих. Есть много уроков, которые можно извлечь для будущей пользы, особенно о
том, как и когда начинать проект, как формулировать экономическое обоснование, привлечь
различные заинтересованные стороны. Нельзя смотреть на экономическое обоснование как
на простое оправдание финансирования проекта; это должно быть главным руководством
для внедрения проектов. Такие уроки бесценны, и нельзя допустить, чтобы они были поте-
ряны для организации.
9. Устойчивая производительность. У проекта есть вполне определенное время жизни,
тогда как процессы (если они поддерживаются, измеряются и управляются) существуют в
повседневных условиях бизнеса и после окончания проекта. В задачи проекта входит пере-
дача процессов таким образом, чтобы на предприятии понимали, как «содержать» процессы.
В организации должна быть сформирована структура процессов, которая поддерживает су-
ществование (эффективность и продуктивность) процессов.
10. Реализация ценности. Зачем вообще затевают проекты? Чтобы создать и обес-
печить вклад в стратегию организации. Проект только тогда закончен, когда достигнута цель
его существования, а сам он передан предприятию таким образом, что оно может поддержи-
вать результаты проекта. Менеджеру и спонсору проекта нужно обеспечить наличие струк-
туры управления выгодами, чтобы осуществлять мониторинг и реализовывать ценность, ко-
торая происходит из проекта. Также очень важно набрать на протяжении проекта как можно
больше быстрых «легких» выигрышей (насколько это разумно и целесообразно, конечно).
Такие быстрые выигрыши нужно оценивать и реализовать, одновременно собирая информа-
цию об экономии, которую они дают. Это создает финансирование и дальнейший импульс
для проектов BPM. Всегда информируйте всех (все заинтересованные стороны) о выгодах,
извлекаемых из быстрых выигрышей, — это отличный способ продвижения BPM.
Проекты BPM — сложная бизнес-деятельность, требующая выверенного, структуриро-
ванного и упорядоченного подхода к их реализации. На протяжении нашей книги эти важ-
нейшие факторы успеха рассматриваются в практическом плане

Глава 9 Важнейшие аспекты внедрения BPM

Самые важные факторы внедрения BPM — баланс и согласованность ИТ и организаци-
онного (предприятие) аспектов. Правильно выбранный баланс позволит осуществить проект
BPM эффективно и эффектно.
Подходящий образ — Sogeti в Голландии, показанный на рис. 9.1. Ее девиз: «Скорость
(эффектность) и эффективность за счет баланса и согласованности».

Поясним эту метафору:

 скорость (эффектность) — решающий фактор. Главная цель — победить, а победа
достигнута, если на финише вы первый (самый быстрый). В проекте/организации BPM цель
— сосредоточиться на реализации выгод, которые дают бизнес-процессы;
 эффективность связана с обеспечением оптимального использования всей имею-
щейся энергии и энтузиазма для достижения нужного результата (выжать из команды все). В
организации/проекте BPM цель — обеспечить продуктивный вклад каждого участника, до-
статочный для достижения нужных результатов;
 баланс требуется, чтобы лодка не перевернулась и не кренилась, поскольку это не
способствует скорости и эффективности. Баланс достигается тщательным согласованием си-
лы, веса и опыта всех сидящих в лодке. В организации/проекте BPM цель — обеспечить учет
всех элементов внедрения (управления, процессов, людей, управления проектом, ресурсов и
информации) в реализации решения;
 согласованность требуется, чтобы команда гребцов работала как единый механизм —
в одном ритме и в одной манере, что обеспечит высокую скорость. В организации/проекте
BPM важна согласованность всех элементов внедрения, которые по отдельности не рассмат-
риваются;
 процесс — это загребной, который задает ритм остальным гребцам. В организа-
ции/проекте BPM ведущая роль принадлежит бизнес-процессам, а персонал и технологии
должны следовать за ними;
 управление (менеджер проекта, руководитель процессов, спонсор проекта) ведет лод-
ку прямо к финишу, так что она не утыкается в берег и не сбивается с курса. Если организа-
ция/проект BPM слишком много веса придает ресурсам и информации (аспекты ИТ), проект
«затолкают на обочину» организации и он застрянет там, (например, не убежденный персо-
нал). Если же организация/проект BPM придает излишний вес персоналу или процессам (ас-
пекты организации), то «лодка» проекта может застрять на «берегу» ИТ (например, ресурсы
— ПО и оборудование, — которые не способны обеспечить достижение желаемых результа-
тов.
Глава 10. Почему необходим структурированный подход к внедрению BPM
Синдром «вершины айсберга», описанный в главе 1, показывает, что восприятие орга-
низацией программы BPM, — вероятно, лишь видимая над ватерлинией часть на уровне
проекта, однако реальность такова, что большая часть усилий внедрения невидима, по-
скольку находится ниже ватерлинии. Проекты BPM — не самоцель. Смысл BPM — в воз-
можностях бизнеса, которые может открыть BPM, если каждый менеджер и сотрудник орга-
низации проникнется идеей процессного взгляда. Разумеется, часто BPM начинается именно
с проекта, но нужно предпринять колоссальные усилия, чтобы традиционный статус проекта
превратился в обычную повседневную работу предприятия.
Традиционный подход большинства предприятий к проектированию усовершенствова-
ния процессов можно продемонстрировать с помощью цикла Деминга [78]: план, действие,
сверка, реакция. Со временем этот цикл эволюционировал в форму, представленную на рис.
10.1, где показаны привычные шаги, выполняемые в рамках проекта совершенствования
бизнеса, например:
1. анализ совершенствуемых сфер, понимание целевых показателей предприятия, сбор
требований заинтересованных сторон и выбор процессов, которые будут усовершенствованы
в первую очередь.
2. Достаточно подробное изображение «текущего состояния (как есть)», позволяющее
понять процесс и решить, как его усовершенствовать.
3. Достижение согласия внутри предприятия по срокам перестройки процессов и вы-
полнение шага «Будет так (как будет – С.К.!)» по проектированию процессов.
4. Внедрение вновь спроектированных процессов.

Ранее большинство организаций останавливалось на этом шаге, считая, что внедрение

вновь спроектированных более эффективных процессов само по себе является успешным
проектом. Во многих случаях через 18–24 месяца проект пересмотра процессов повторялся,
поскольку бизнес менялся, и процессы в результате переставали отвечать его требованиям.
Чтобы справиться с постоянной необходимостью все время вести новые проекты усо-
вершенствования бизнес-процессов следует иметь программу непрерывного совершенство-
вания процессов, чтобы изменять их в ходе изменения бизнеса. Этим замыкается кольцо об-
ратной связи.
Один из главных вопросов при таком подходе можно сформулировать так: а решается ли
именно та проблема, которую нужно решить? Как можно убедиться, что вновь разработан-
ные процессы действительно способствуют стратегической перспективе или устремлениям
предприятия?
Стейси (Doug Stace) и Данфи (Dexter Dunphy) [71] утверждают, что «… стратегия за-
ключается в поиске направлений, которые питают жизнь организации; структуры обеспе-
чивают социальное наполнение, необходимое для содействия стратегии … Чтобы быть
эффективными, стратегия и структура должны постоянно пересматриваться и пере-
страиваться для согласованности».
Итак, в первую очередь нужно, чтобы стратегия организации, и ее структура поддержи-
вали друг друга. Достаточно ли этого?
С.К. Прахалад (C. K. Prahalad), выступая на Гарвардском коллоквиуме «Нарушаем ко-
декс изменений» (Breaking the Code of Change) в августе 1998 года, описал три программных
направления, которые постоянно и одновременно должны работать вместе:
1. интеллектуальное направление. Некоторые называют это стратегией, другие — стра-
тегической перспективой или стратегическими устремлениями. На рис. 10.2 это названо
«Цели организации и показатели организационного успеха».
2. Управленческое направление. Включает структуры, технологии и системы организа-
ции, в том числе выбор управленцами способа применения и перемещения ресурсов внутри
организации, чтобы отвечать ее потребностям. Мы включили процессы непосредственно в
это направление, что отображено на рис. 10.2 в колонке «Управление организацией».
3. Поведенческое направление. Сюда входит культура, ценности, этические нормы,
стиль руководства, обучение персонала, навыки и основные показатели производительности
сотрудников. Здесь важно обеспечить адекватное реагирование системы вознаграждений и
стимулирования на поведенческую модель, которую вы ходите продвигать и поощрять. На
рис. 10.2 это показано в последней строке «Производительность и измерения».
В выступлении Прахалада справедливо указано, что организация должна работать од-
новременно по всем трем направлениям.
Перед руководством и управлением предприятия стоит вызов: принять эти три направ-
ления как стратегические и определить их практическое применение на предприятии. Румм-
лер и Брах (Rummler, Brache) [65], а также Хармон (Harmon) [29] показали, как можно рабо-
тать по этим трем направлениям, каждое из которых имеет собственные показатели произ-
водительности и требования продуктивности, что воспроизведено на рис. 10.2. Это дает пре-
красное описание уровней производительности, потребностей результативности в организа-
ции и применения трех направлений, сформулированных Прахаладом.
 Большинство организаций, собирающихся усовершенствовать бизнес-процессы, начина-
ет с центральной клетки — «Конструирование/проектирование и внедрение процессов». Вы-
полняется моделирование состояния «как есть» и «как будет» в будущем, реализация новых
перестроенных процессов, после чего начинаются размышления, почему результаты не все-
гда совпадают с теми, на которые рассчитывали.
Лео Льюис (Leo Lewis, 1993) [42] указал, что «путь реинжиниринга вовсе не усыпан цве-
тами … Согласно некоторым статистическим данным, семь из десяти проектов реинжини-
ринга не удаются». В большинстве обследованных компаний лишь менее 5% изменений до-
стигнуто за счет реинжиниринга (Бюллетень психолога организации, 1995).
Кейс: важность понимания стратегии организации
К нам обратились с просьбой проанализировать действующие процессы операционной
деятельности организации и дать рекомендации по программе совершенствования работы.
Было выдвинуто два предложения. Первое — в пользу «ползучего» (постепенного) улучше-
ния процессов; второе предусматривало автоматизацию BPM. Интересно отметить, что оба
предложения отвечали поставленным целям процессов, которые были задокументированы
заказчиком. Поэтому мы обратились к нему с просьбой описать стратегию организации на
ближайшие три года.
Стратегические устремления организации в связи с программой были сформулированы
так: разработанная стратегия должна вывести нас на передовые позиции, далеко опере-
жающие конкурентов, так что им будет трудно сравняться с регулярно демонстрируемым
уровнем процессов и систем сервиса. Это должно стать основой нашего конкурентного
преимущества в кратко- и среднесрочном плане.
Вариант постепенного улучшения давал медленные улучшения. Только три из двадцати
пяти процессов можно было перестроить полностью; остальные удалось бы лишь слегка
подправить.
Вариант автоматизации BPM обеспечивал значительные новшества и интеграцию с дру-
гими важнейшими системами, а также способность организации сохранять маневренность
бизнеса.
Вывод. Нашему заказчику стало ясно, что надо остановиться на варианте автоматизации
BPM. Если у менеджера проекта нет ясного понимания стратегии организации, и он не обес-
печивает соответствие проекта этим целям, а также вклад проекта в эту стратегию, есть
большая опасность, что проект решает не ту проблему, которую нужно решить.
Как можно заново спроектировать процессы, не зная, чего вы хотите добиться проектом
— каковы новые цели (или цель) процесса? Собираетесь ли вы сократить время обработки с
пяти до двух дней или двух часов? Если цель — два часа на обработку, то подход к проекти-
рованию процесса будет кардинально отличаться от двухдневного подхода. Нацелены ли вы
на повышение качества предлагаемого обслуживания, даже если это может привести к уве-
личению сроков обработки некоторых транзакций? Подход к пересмотру процессов будет
абсолютно разным в зависимости от ответов на эти вопросы.
Но теперь нужно спросить: а как узнать, что процесс дает вклад и ценность в стратегию
организации? Даже если известны цели процесса, и он перестроен таким образом, чтобы до-
стигать этих целей, будет ли это отвечать стратегическим целям организации и вносить
вклад в их достижение?
Увязав стратегию организации с целями поддерживающих процессов и создав вновь
сконструированные процессы, необходимо спросить: кто реализует эти процессы? Ответ:
персонал организации. Если структура организации, должностные роли, профессионально-
квалификационные требования и система вознаграждений и поощрений не поддерживают
стратегию организации, то лишь первые два стратегических направления по Прахаладу бу-
дут работать.
Когда решены все эти вопросы, организация должна обеспечить постоянное «управле-
ние» и совершенствование бизнес-процессов.
Реализация проекта BPM — многогранная и сложная работа, и если не принять структу-
рированного подхода, то либо ничего не получится, либо получится не то, что ожидали за-
интересованные стороны. Однако слишком жесткое применение методик или схем не дает
гибкости, необходимой для ответа на меняющиеся вызовы.
 Нужен практичный, всесторонний и структурированный подход, который можно адап-
тировать к каждой конкретной организации. Нами разработана зарекомендовавшая себя об-
щая схема, в рамках которой такой подход обеспечивается для использования при реализа-
ции проектов и программ BPM. Эта схема охватывает всю «реальную» деятельность, нахо-
дящуюся ниже «ватерлинии айсберга» проекта BPM и состоит из десяти этапов и трех
неотъемлемых компонент-составляющих. Каждый этап разбивается на логические шаги, ко-
торые при правильном и точном исполнении обеспечат успех проекта.
Названные этапы, неотъемлемые компоненты-атрибуты и логические шаги, увязанные в
схему, вполне укладываются в представления здравого смысла. Однако, согласно приписы-
ваемому Марку Твену изречению, «здравый смысл наиболее необычен». По нашему опыту,
даже если люди знают все это, они редко исполняют все этапы правильно, в логической по-
следовательности, а то и не исполняют совсем. Наша общая схема группирует различные ас-
пекты проекта BPM в логическую цепочку. Однако, как уже отмечалось выше, схема или
методика может оказаться как спасательным кругом, так и камнем на шее. Поэтому важно
применять схему и методики согласно нуждам организации.
Заключение
Строгая, но одновременно гибкая методологическая схема необходима для содействия
улучшениям бизнес-процессов. Наш подход к BPM признает, что в идеале изменения долж-
ны продвигать люди изнутри организации, у которых имеется четкое видение процессов и их
целей, когда роли и распределение ответственности и подчиненности прозрачны, а системы,
процессы и технологии поддерживают конечную цель организации. Однако такая ситуация
встречается редко, поэтому общая схема дает возможность лучше и глубже понять суть биз-
нес-процессов. Схема также обеспечивает структурированный подход на всем протяжении
проекта BPM: от его зарождения и инициирования до завершения и перехода в обычный ре-
жим работы.
 Часть II. Общая схема
В этом разделе рассмотрена общая методическая схема внедрения BPM, различные эта-
пы и шаги этого внедрения, и показано, как ее применять для успешной реализации проектов
BPM.
В главе 11 дается описание схемы, десяти этапов и трех необходимых компонентов-
атрибутов, которые считаются неотъемлемой частью любого проекта BPM.
В главе 12 поясняется, каким образом можно применять схему с указанием двух типич-
ных способов инициирования проектов BPM и получающихся в результате четырех сцена-
риев реализации, обычно выбираемых организацией.
Затем в главах 13–22 подробно разъясняется каждый из десяти этапов, а в главе 23 вво-
дится три необходимых компонента, которые в свою очередь описаны в главах 24–26.
Для применения схемы важно помнить, что хотя этапы описаны последовательно и
обычно осуществляются именно в таком порядке, это не всегда соблюдается. Возможны си-
туации пропуска этапа (например, этап понимания можно пропустить, если нет нужды в по-
нимании существующих процессов, как в случае стартующей «с нуля» организации). Анало-
гично, некоторые шаги внутри этапов также могут выполняться в иной последовательности,
нежели описаны. Однако, хотя такие случаи возможны, мы настоятельно рекомендуем тща-
тельно рассмотреть каждый этап и шаг, и если группа проекта принимает решение о его
ненужности, это должно быть задокументировано и доложено руководящему комитету про-
екта с указанием причин.
Настоятельно рекомендуется полностью ознакомиться с разделом, посвященным общей
схеме, до начала проекта BPM. В предыдущем абзаце указана одна из причин для этого.
Другая причина заключается в том, что некоторые этапы (например, этап реализации полез-
ности или ценности) не разделяются на шаги, поскольку они должны быть осуществлены на
других этапах общей схемы. Этапы строятся в виде отдельных шагов с целью акцентировать
их важность для группы проекта и организации, чтобы убедиться, что, как в случае этапа ре-
ализации ценности, группа проекта стремится к воплощению выгод, обозначенных в обосно-
вании проекта.
Важно также четко осознавать, что инициативы BPM могут реализовываться в форме
«проекта» или «постоянного совершенствования» в рамках предприятия. Описываемая в ча-
сти II общая схема применима к проекту BPM. Этап устойчивого функционирования, о ко-
тором говорится ниже, нужен для перехода из состояния «проекта» в режим повседневной
работы. Часть III посвящена вживлению BPM в ткань организации, чтобы обеспечить посто-
янство управления процессами и их совершенствования, хотя в случае постоянного широко-
масштабного усовершенствования BPM, оправдывающего развертывание проекта, схему
снова можно применять во всей ее полноте.
 Глава 11. Обзор общей схемы
В литературе о процессах тремя важнейшими аспектами считались люди, процесс и си-
стемы. С этим можно согласиться, однако в части «систем» сегодня нужна более широкая
интерпретация, и мы используем слово «технологии». Мы также добавили четвертый важ-
нейший компонент: управление проектами. Для иллюстрации четырех важнейших компо-
нентов мы предложили «треногу» успеха проекта (рис. 11.1).

Три элемента (три опоры треноги) сохраняются, однако добавляется четвертый элемент
— платформа, на которой зиждется «успех». Важно и основание, на котором стоит «трено-
га». Перечислим три опоры:
1. Процесс. Необходим соответствующий уровень обновления бизнес-процессов, увя-
занный со стратегией организации и задачами процессов, а также осознание важности про-
цессов в организации.
2. Люди/персонал. По мере роста зрелости организации по отношению к управлению
процессами приходит понимание того, что персонал является ключом к внедрению новых
процессов. В организации должны иметься соответствующие схемы измерения и управления
производительностью. Управление процессами должно быть активным, упреждающим, а не
реагировать на происшествия. Наряду с прочим, все это строится вокруг человеческого фак-
тора проекта BPM.
3. Технологии. Данный термин обозначает вспомогательные инструменты и средства для
процессов и персонала, и не обязательно подразумевает программные средства BPM или
приложения (хотя может обозначать и их).
4. Четвертый компонент, скрепляющий вместе эти опоры — «платформа» управления
проектами, потому что без правильно ведущегося проекта внедрение обречено на провал.
Если одна из опор отсутствует, тренога упадет, а без скрепляющей платформы упадут
все опоры, и проект не оправдает ожиданий. Проекты BPM сложны, и их удача зиждется на
правильном исполнении всех аспектов проекта. Эти аспекты представлены в виде основания,
на котором стоят опоры. Если основание непрочное (или строится неудачно), тренога рух-
нет, разрушится. Если же основание твердое, потому что строится правильно, тренога будет
стоять на надежной основе, и проект удастся.
Распространены попытки реализации организациями значительных проектов BPM без
должного учета всех четырех компонентов и элементов основания. Как и в случае с трено-
гой, непрочная или отсутствующая опора приведет к провалу проекта.
В целом, все компоненты и элементы основания, на которых зиждется проект, реализу-
ются разными людьми (или группами людей). Эти группы не всегда полноценно общаются
друг с другом и не координируют свою работу. Фактически, высказывается мнение, что под-
разделение ИТ, бизнеса и клиенты просто говорят на разных языках. Управление проектами
в организациях часто также находится на низком уровне.
 Результативное выполнение всех четырех компонентов и элементов основания требует
различных подходов, навыков и умений. Симптомы неспособности организации справиться
с компонентами таковы:
 в организации не знают, с чего начать;
 нет предполагавшегося или запланированного продвижения;
 приобретен технологический инструмент в надежде, что это решит все вопросы;
 перестроенные процессы не реализуются;
 реализуются неудовлетворительные выгоды;
 неверна причина, по которой совершенствуются процессы («так поступают все, а мы
чем хуже»);
 BPM слабо влияет на организацию, возможно, поскольку масштаб внедрения слиш-
ком велик, слишком мал, или организация старается ставить слишком амбициозные цели.
Хотя, очевидно, существует много общего между организациями, акценты, которые
необходимо расставить для применения этих компонентов и элементов, а также основания
внедрения BPM могут различаться не только между организациями, но и в рамках одной ор-
ганизации. Например, много говорят о необходимости увязывать проект или программу
BPM со стратегией организации. Хотя такая цель очень приветствуется, это не единственная
сфера в организации, где необходима увязка. Перед тем как организация сможет взяться за
совершенствование процессов, необходимо понять факторы, которые на это влияют. Пока
нет полного осознания культуры и поведения персонала, использующего процессы, невоз-
можно узнать, какие изменения будут эффективны.
Поэтому речь идет об увязке не только стратегии и процессов, но и персонала и моделей
поведения. Проект BPM также зависит от измерений и управления производительностью,
управления изменениями и взаимного общения. Эффективный обмен информацией и взаи-
мосвязи между всеми уровнями организации исключительно важны для успеха проекта
BPM.
На рис. 11.2 показаны упомянутые в главе 10 этапы и важнейшие неотъемлемые атрибу-
ты общей схемы. Следует держать этот рисунок в памяти при чтении данной главы.

Результаты в организации зависят от того, насколько синхронизированы важнейшие

компоненты:
 стратегическое устремление;
 стратегическая перспектива (видение);
 исполнение;
 ценности/культура/модели поведения;
 персонал.
Увязка стратегии, видения перспективы и проектов совершенствования процессов внут-
ри организации даст возможность более полной реализации стратегии. В статье в июльском
выпуске Harvard Business Review 2003 года, озаглавленной «What really works» [54], авторы
выделили четыре основные сферы (стратегию, исполнение, культуру и структуру) и четыре
вторичные сферы (таланты, лидерство, инновации, слияния и поглощения), в которых
успешно работающие организации показывают исключительное качество исполнения. Авто-
ры исследования установили, что такие организации отличались успешным функционирова-
нием во всех четырех основных сферах и, по крайней мере, в двух из четырех вторичных.
Любопытно отметить, что стратегия и исполнение — две из четырех основных сфер. «Ис-
полнение» в этой связи определяется авторами как «разработка и поддержание операционно-
го исполнения». Это исследование показало, что успешные организации выбирали самые
важные процессы с точки зрения удовлетворения клиентских запросов и старались сделать
их максимально эффективными и продуктивными. В таких организациях также были четко
сформулированы показатели эффективности процессов.
Подобное увязывание необходимо распространить на показатели производительности по
всей организации. Для успеха организации необходимо, чтобы показатели производительно-
сти руководителей, менеджеров, глав коллективов и сотрудников были увязаны со стратеги-
ей и двигали организацию в том же направлении.
Чтобы успешно реализовать программу совершенствования бизнес-процессов, ее необ-
ходимо направлять и контролировать целостным последовательным подходом к реализации,
иначе в нее будут привнесены значительные дополнительные риски. Такой подход к реали-
зации позволит предприятию расширить ценностное наполнение основных элементов успеха
организации, если только он воплощается в каждом отдельном проекте, в идеале — в рамках
программы BPM.
Теперь каждый из уровней будет рассмотрен более подробно, чтобы показать взаимо-
связи между ними и продемонстрировать, как нужно применять последовательный подход
по всей организации.

Общая схема внедрения BPM. Разработка проекта или программы BPM и схемы реа-
лизации проекта, которая подходит любой организации и годится во всех ситуациях, — за-
дача чрезвычайно сложная, особенно для разных организаций. Но если организации и оди-
наковые, подход к внедрению BPM сильно меняется в зависимости от особенностей органи-
зации и даже внутри нее.
Наш опыт консультантов BPM и практиков внедрения дал возможность разработать та-
кую общую схему, и мы ее применяли и дорабатывали по ходу реализации программ и про-
ектов BPM. Схема состоит из десяти этапов. Ниже мы немного подробнее остановимся на
каждом из них, а в последующих главах они рассматриваются детально. Итак, десять этапов:
1. стратегия организации.
2. Архитектура процессов.
3. Стартовая площадка.
4. Понимание.
5. Инновации.
6. Персонал.
7. Разработка.
8. Реализация/внедрение.
9. Реализация ценности.
10. Устойчивое функционирование.
Подход организаций к способам внедрения BPM. Хотя совершенствование бизнес-
процессов в большинстве организаций считается приоритетом, их подходы к BPM или реа-
лизации усовершенствования процессов разнятся в огромной степени. Поэтому для обеспе-
чения значимого успеха проектов необходимо разработать схему или методику реализации,
которые учитывали бы все возможные варианты. А это весьма непростая задача. В следую-
щей главе предлагаются два метода выбора или инициирования проектов BPM в организа-
ции.
На рис. 11.3 представлены этапы 1 и 2 общей схемы, а на последующих рисунках пока-
зано, как эти этапы встраиваются в постепенную реализацию программы BPM во всей орга-
низации.
 Проекты обычно начинаются с этапа стартовой площадки, когда на предприятии:
1. выбирается подразделение для совершенствования работы или устанавливается
необходимость такой деятельности,
2. определяется объем проекта, он
3. утверждается и
4. запускается (рис. 11.4).
Начиная с этого момента, этапы понимания, инноваций, развития и внедрения опреде-
ляют ход каждого отдельного проекта и обеспечивают согласованность схемы или подхода
во всех проектах.

На заключительных этапах (рис. 11.5) группа проекта должна работать с бизнес-

подразделениями, чтобы:
1. реализовать ожидаемую полезность (ценность) или выгоды проекта, сформулиро-
ванные в обосновании, и
2. обеспечить беспроблемный переход от «проектного» режима к нормальной рабо-
те (повседневному функционированию организации).
Это переведет проект из «проектного» состояния в устойчивое функционирование.

На рис. 11.6 показано, что на протяжении всего проекта должна осуществляться под-
держка необходимых компонентов-атрибутов в виде:
1. управления проектами,
2. управления изменениями персонала и
3. лидерства преданного проекту руководства.
Без этих необходимых компонентов риск проекта многократно возрастает.
 После успешной реализации в организации нескольких проектов BPM можно запускать
проекты последовательно, т.е. следующий проект сразу после успешного старта предыдуще-
го.
Любая принятая организацией схема должна быть структурно достаточно гибкой и ши-
рокой, чтобы адаптироваться к каждому отдельному проекту, программе и подходу органи-
зации. Предлагаемая нами схема предназначена обеспечить такую гибкость и широту за счет
комплекса этапов и шагов, которые позволяют справиться с вызовами, стоящими на пути
внедрения BPM.
Схема построена таким образом, чтобы дать возможность организации перескочить че-
рез этап или пропустить какие-то его шаги, если они неприменимы для конкретного выбран-
ного сценария реализации (об этом подробнее в главе 12).
В предлагаемой схеме десять этапов и три дополнительных компонента называются не-
обходимыми, поскольку являются важнейшими неотъемлемыми атрибутами любого проек-
та BPM (рис. 11.7). Хотя в определенных сценариях реализации поначалу некоторые этапы
можно полностью или частично пропустить, мы считаем, что в конечном итоге все органи-
зации должны возвращаться к пропущенным этапам и завершать их, если BPM или ориенти-
рованный на процессы взгляд принимаются как важнейший элемент бизнес-стратегии серь-
езно.

Каждый этап включает ряд шагов, которые формируют детализированный, структуриро-

ванный, но гибкий подход к реализации проекта BPM. Шаги:
1. не только указывают, какие работы должны быть выполнены на каждом этапе, но и
2. дают понимание взаимосвязей между этапами.
Этапы общей схемы. Ниже кратко описан каждый из этапов и необходимых компонен-
тов. В последующих главах дается более подробное описание.
1. Стратегия организации. На данном этапе необходимо добиться ясного понимания
стратегии организации, перспектив, стратегических целей, движущих сил бизнеса и стиму-
лов исполнения всеми членами группы проекта. Ожидают ли заинтересованные стороны по-
лучить выигрыш от проекта в краткосрочном или долгосрочном плане? Является ли предло-
жение ценности организации ясным и понятным для всех? Важно понимать, что стратегия —
это не план, а «целенаправленный процесс привлечения людей изнутри и извне организации
к прокладыванию новых путей вперед» [71]. Стратегию нужно объяснять всем заинтересо-
ванным сторонам (особенно руководству и сотрудникам) и убеждать их в ее правильности,
пока она не укоренится в культуре организации. Персонал должен проникнуться предлагае-
мой стратегией и увлеченно воспринять ее. Группа проекта должна знать и понимать страте-
гию; тогда направленность и наполнение проекта будут давать вклад в реализацию страте-
гии.
2. Архитектура процессов, т.е. средство формирования комплекса правил, принципов,
методических указаний и моделей для внедрения BPM по всей организации. Архитектура
процессов образует основу для замысла и реализации инициатив проектов BPM. Именно в
ней ИТ и бизнес-архитектура увязываются со стратегией организации.
3. Стартовая площадка. На данном этапе достигается три основных результата:
o выбор подразделения, в котором будет стартовать первый (или следующий)
проект BPM;
o согласование задач и/или видения процессов, как только процессы выбраны;
o формальная организация выбранного проекта.
С чего начать? Этот выбор труден сам по себе, но схема дает несколько способов опре-
делить, где и как начинать. Задачи и видение процессов нужно увязать со стратегией органи-
зации и архитектурой процессов, чтобы быть уверенным, что они вносят ценный вклад или
содействуют стратегии. Определив бизнес-подразделения, выбрав процессы и согласовав их
задачи, необходимо организовать проект, чтобы вероятность его успеха была максимальна.
Организация проекта включает структурное определение группы проекта, его объема, рабо-
ты с заинтересованными сторонами, разработку исходного обоснования и формулировку
ожидаемых выгод для бизнеса.
4. Понимание. На этом этапе формируется понимание существующей среды бизнес-
процессов, достаточное для перехода к этапу инноваций. Важно собрать хотя бы базовые
элементарные метрики процессов, чтобы иметь возможность установить точку отсчета для
затрат процессов в целях сравнения на будущее. Другие важные шаги — анализ корневых
причин и выявление возможностей получить быстрый выигрыш. Нужно находить, а в идеале
— реализовывать, быстрые выигрыши по ходу проекта, поскольку предприятие не станет
неограниченно финансировать проекты совершенствования процессов (и этого не следует
делать). Идеальная ситуация — выход проекта (проектов) на самофинансирование за счет
выгод, получаемых при реализации таких быстрых выигрышей.
5. Инновации. Данный этап проекта — творческий и часто наиболее интересный. В нем
должна участвовать не только группа проекта и предприятие, но и соответствующие заинте-
ресованные стороны, как внутренние, так и внешние. После определения вариантов новых
процессов, возможно, понадобится выполнить имитационное моделирование, учет затрат по
типам деятельности, планирование ресурсов и проверить целесообразность реализации, что-
бы окончательно выбрать наилучший вариант. Следует сформулировать дополнительные
метрики, чтобы их можно было сравнить с базовыми, полученными на этапе понимания.
Выявляются и выстраиваются в порядке приоритета новые возможные быстрые выигрыши.
6. Разработка. Данный этап включает построение всех компонентов для внедрения но-
вых процессов. Важно понимать, что в данном контексте «построение» не обязательно озна-
чает выстраивание ИТ, а может означать развертывание всей инфраструктуры (столы, ПК,
здания и т.п.) для поддержки программы по изменениям персонала и помощи сотрудникам,
исполняющим процессы. Включает также тестирование программного обеспечения и обору-
дования.
7. Персонал. Важнейший этап схемы, который может поставить под угрозу всю осталь-
ную часть проекта, если его не выполнить тщательно и на уровне лучших стандартов. Этот
этап предназначен обеспечить соответствие функционала, ролей и показателей производи-
тельности стратегии организации и задачам процессов. В конце концов, именно от людей
зависит эффективность и продуктивность процессов, какова бы ни была степень автоматиза-
ции. Данный этап нельзя смешивать с управлением изменениями персонала, поскольку вни-
мание ему должно уделяться на всех этапах проекта.
 8. Реализация/внедрение. На этом этапе собственно и осуществляется внедрение, т.е. во-
площаются в реальность все наработки (вводятся новые процессы, функциональные обязан-
ности, управление и измерения показателей производительности). Планы внедрения имеют
огромное значение, как, впрочем, планы отступления на исходную позицию и планы дей-
ствий на случаи непредвиденных обстоятельств. Во многих организациях полагают, что про-
ект завершается успешным внедрением. По нашему же мнению, следующие два этапа явля-
ются наиважнейшими в проекте BPM.
9. Реализация ценности. Цель данного этапа — обеспечить реализацию выгод, сформу-
лированных в обосновании проекта. Этап включает реализацию выгод, процесс управления
реализацией и отчетность о реализации выгод. Если выгоды не реализованы, организации не
следует предоставлять дополнительное финансирование, чтобы продолжать процессные
проекты. Реализация преимуществ — задача группы проекта, хозяина и спонсора проекта и
предприятия. Хотя этот этап поставлен в схеме девятым, он не является отдельным, по-
скольку некоторые его шаги осуществляются и на предыдущих этапах. Поэтому читателю
рекомендуется изучать соответствующий раздел данной главы вместе с остальными этапами.
Шаги этапов сгруппированы в данной главе так, чтобы обеспечить всестороннее видение ро-
ли, которую играет реализация ценности в проекте BPM, а также гарантировать, что после
этапа внедрения группа проекта BPM займется фактической реализацией выгод, сформули-
рованных в обосновании проекта.
10. Устойчивое функционирование. Совершенно необходимо, чтобы группа про-
екта работала совместно с бизнес-подразделениями при формировании процессной структу-
ры, обеспечивающей устойчивость постоянного совершенствования процессов и их опера-
тивной доработки. Значительные ресурсы, вложенные в проекты, нужно поддерживать и
расширять. Организации должны сознавать, что у процессов есть время жизни, и необходи-
мо постоянно совершенствовать их после достижения проектом целевых показателей усо-
вершенствований. В противном случае по мере изменения бизнеса процессы в организации
не будут работать оптимально. Этот этап заключается в переходе от «проектного» состояния
в режим обычной бизнес-деятельности.
Важнейшие неотъемлемые атрибуты
Обратимся теперь к трем важнейшим атрибутам проекта BPM. Это неотъемлемые ком-
поненты, на которых зиждется любой успешный проект BPM, и они проходят красной ни-
тью по всем этапам схемы проекта:
1. управление проектами. Наши клиенты часто спрашивают:
 может ли обычный менеджер бизнес-проекта или приложения реализовать проект.
Ответ — да, но с оговоркой, что опытный менеджер проекта BPM сделает это намного луч-
ше. Риски проекта в первом случае будут существенно выше, а организация может упустить
многие из выигрышей, обеспечиваемых BPM.
 Может ли человек без большого опыта управления проектами реализовать проект
BPM? Ответ прост — нет. Владение управлением проектами — фундаментальное качество
и требование в любом проекте, в т.ч. и проекте BPM. На самом деле, требования в последнем
случае даже выше в силу возросшей сложности проектов BPM.
2. Управление изменениями персонала. Мы считаем изменения важным элементов, по-
скольку это непосредственно относится к реализации аспектов проекта BPM, связанных с
персоналом. Написано множество статей о причинах неудач проектов совершенствования
процессов и BPM, и мы не намерены приводить их здесь. Тем не менее, ширится убеждение,
что человеческий фактор в проектах совершенствования не всегда рассматривается доста-
точно подробно. Как указал Майкл Хаммер [23], «выдвинуть идеи относительно просто.
Трудно воплотить в жизнь. Реформы застревают и умирают в окопах». А кто сидит в «око-
пах»? Люди, работающие в организации.
3. Лидерство/ведущая роль. Все специалисты по изменениям бизнес-процессов сходятся
во мнении, что для успеха любой программы перемен она должна опираться на поддержку
руководства / лидеров высшего ранга. По словам Кина (Keen) [38], «твердое намерение этих
руководителей добиться изменений значит больше, чем тщательный план изменений». Для
эффективности проектов BPM чрезвычайно важно то, насколько руководители-лидеры деле-
гируют ответственность. Нам приходилось сталкиваться и с весьма успешными внедрениями
BPM и наблюдать несколько не слишком удачных, но общей чертой их всегда была настой-
чивость, убежденность, внимание и зрелость исполнительного руководства — лидеров.
 Если теперь свести вместе три важнейших атрибута проектов BPM и изобразить на диа-
грамме их взаимосвязи, мы получим рис. 11.8, где показано, что часто проект BPM распола-
гается над линией видимости, тогда как операционная бизнес-деятельность находится ниже
линии видимости. Управление проектами относится к проектам, а управление изменениями
персонала — к обычной повседневной деятельности, потому что именно там и сосредоточе-
ны люди. Роль руководства состоит в том, чтобы гармонично и гладко свести вместе два
этих важнейших компонента.

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

нужно адаптировать к конкретной организации и ситуации. Более подробно применение
схемы рассмотрено в главе 12.
Организация, ориентированная на процессы
Ниже мы обращаемся к организациям, ориентированным на процессы, так что полезно
убедиться, что у нас единое понимание этого термина. Проще всего описать ориентирован-
ную на процессы организацию, сравнив ее с организацией, не являющейся ориентированной
на процессы (табл. 11.1).
Таблица 11.1. Сравнение ориентированной и не ориентированной на процессы органи-
заций
Параметр сравнения Организация

ориентированная на про- не ориентированная на процес-

цессы сы

вклад процессов в органи- сознает не полностью осознает

зацию и реализацию стра-
тегии организации (выиг-
рыш и польза)

фокус внимания на управ- вживлено в практическое не вживлено в практическое

лении процессами (BPM) управление управление

стратегия и инициативы принимает стратегию поддерживает разнообразные

BPM инициативы

высшее руководство нацелено на процессы (осо- понимает, что процессы играют

бенно высший руководи- важную роль из-за проблем, кото-
тель) рые они вызывают (качество, от-
ставания по срокам и т.п.)

четкое понимание процес- имеется имеется, но некоторые процессы

сов смоделированы с помощью не-
сложных средств моделирования;
модели процессов не связаны и не
состыкованы

выстраивание организаци- вокруг процессов, либо на по принципу функциональных

Параметр сравнения Организация

ориентированная на про- не ориентированная на процес-

цессы сы

онной структуры основе матрицы процессов и подразделений

функциональных обязанно-
стей

проблемы между подраз- понимает возможность су- разочарована и может возлагать

делениями ществования и имеет дей- вину на менталитет; возможно,
ственные механизмы для их намерена ввести (или уже ввела)
выявления и устранения соглашения об уровне взаимодей-
ствия между подразделениями

ответственность за процес- руководитель высокого ран- функционал распределяется по

сы га подразделениям

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

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

Глава 12. Методические указания по использованию общей схемы

В предыдущих главах было введено понятие общей схемы и подчеркнута важность
структурированного подхода к проектам BPM. В этой главе поясняется, как пользоваться
общей схемой, пройдя путь, которым организация приходит к проектам BPM, а также вы-
бранным впоследствии сценарием реализации проекта.
Почему не работает универсальный подход «один алгоритм на все случаи жизни»?
Трудность любого структурированного подхода к бизнес-проектам, будь то проект BPM
или любой другой, в том, что организации часто исповедуют философию одного подхода на
все случаи жизни.
Распространено мнение, что проект BPM нужно начинать, заручившись полной и без-
раздельной поддержкой руководителя организации, и, несомненно, этот вариант идеален. На
практике, однако, большинство руководителей фирм либо:
 просто не знают о проекте BPM,
 не интересуются им, потому что считают его «просто очередным проектом».
И даже если руководителю известно о проекте BPM, и этот проект — один из первых
проектов BPM в организации, ему, возможно, понадобятся доказательства выгод, которые
может принести BPM.
Но даже если руководитель организации и проявляет интерес, он часто не уделяет долж-
ного внимания, времени и ресурсов инициативе BPM. Бизнес-процессы происходят в самой
организации, и их мониторинг, управление и совершенствование требуют не просто под-
держки на словах. Недостаток уделяемого внимания, времени и ресурсов может оказать су-
щественное негативное влияние на реализацию инициативы BPM.
Помимо этого, большинство подходов не учитывает различия опыта вживления BPM: от
начальной ориентации BPM как важной составляющей управления, до окончательного при-
нятия в повседневной деятельности. Очевидно, подходы будут фундаментально различаться
в зависимости от опыта организации в области BPM.
В идеале у организации есть сформулированное и опубликованное стратегическое виде-
ние перспективы, целевые показатели и задачи. Организация берет на вооружение BPM, вы-
страивает стратегию в увязке с BPM и принимается за формирование архитектуры процессов
— это столпы, на которых можно строить отдельные проекты. Кроме того, архитектура про-
цессов увязывается со стратегией организации и архитектурой бизнеса и ИТ. Однако часто
ситуация далека от идеальной.
Как выбирают проекты BPM?
Причина, по которой организация приходит к решению о необходимости проекта BPM,
оказывает определяющее влияние на то, как будет вестись проект, и каким образом общая
схема будет применяться организацией и группой проекта.
Мы считаем, что существует два основных метода запуска проектов BPM организация-
ми:
1. движимый стратегией - метод оказывает существенное влияние на то, почему, где и
как выбирается проект.
2. операционно-инициативный подход - определяется конкретными нуждами организа-
ции, зрелостью ведущей группы в контексте BPM, а также стилем лидерства высшего руко-
водства, исполнительных органов и менеджеров.
Движимый стратегией подход складывается, если стратегия организации реализуется
группой руководства, и переход от стратегии к реализации означает, что руководство при-
шло к выводу, что определенные проекты будут воздействовать на некоторые бизнес-
процессы. Это воздействие потребует изменения или перестройки ряда бизнес-процессов,
что означает запуск проектов BPM. Такая ситуация представляет собой управление бизнес-
процессами организации «сверху вниз». Поэтому портфель проектов BPM будет формиро-
ваться, планироваться и пересматриваться в результате выработки стратегии, которая выте-
кает либо из необходимости изменения стратегии, либо из ее периодического анализа.
 На рис. 12.1 показано, как это отразится на общей схеме. Последовательность действий
такова, что стратегия организации предопределит необходимость проекта BPM, а также обо-
значит процессы, которые будут затронуты, а, следовательно, и будут охвачены проектом
BPM. Поскольку с большой вероятностью такая организация уже достаточно опытная в во-
просах реализации BPM, у нее почти наверняка окажется архитектура процессов, с которой
будет сверяться проект на всем его протяжении. На начальном этапе некоторые шаги могут
выполняться не столь тщательно, чем обычно, но структура и группа проектов должны быть
все же сформированы. Остальные этапы схемы также нужно будет выполнить.
Подход операционной инициативы, как и предполагает название, означает инициати-
ву, вызванную операционными нуждами организации, бизнес-подразделения или отдела.
Проекты BPM этого типа, вероятно, предопределяются проблемой бизнеса.
Операционная инициатива означает, что решение о необходимости проекта BPM при-
нимается на более низком уровне в организации, чем стратегия. Вероятным моментом за-
пуска будет, таким образом, стартовый этап. Небольшая группа проекта приступит к не-
скольким шагам данного этапа, чтобы оценить и собрать достаточно информации для точно-
го определения стартовой позиции и глубины проекта (в главе 15 указывается, какие именно
шаги необходимы, и как их следует выполнять). Отсюда следует, что этапы стратегии орга-
низации и архитектуры процессов общей схемы не реализуются в полном виде, а, скорее,
используются лишь для получения определенной информации. Но обеспечение увязки со
стратегией организации остается чрезвычайно важным фактором (рис. 12.2).

Если причина запуска проекта BPM — соблюдение требований законодательства, то

проект должен рассматриваться со стратегической точки зрения. Если проект поддержан вы-
соким руководством, то это, скорее, случай стратегически движимого подхода. Если же
поддержки высокого руководства нет, это операционная инициатива.
Стратегия организации и архитектура процессов являются фундаментом любого проекта
BPM. Чем глубже и крупнее проект, тем прочнее должен быть фундамент. Именно поэтому в
проектах со стратегически движимым подходом на этапах стратегии организации и архитек-
туры процессов должны прилагаться более интенсивные усилия, чем в случае проекта с под-
ходом операционной инициативы.
 Однако независимо от того, как принимается решение о необходимости проекта BPM,
следующее решение, которое должно быть принято организацией, связано с выбором сцена-
рия внедрения проекта BPM.
Четыре сценария внедрения BPM
Мы различаем четыре сценария проектов BPM. Выбор одного из них определяется мно-
гими факторами, которые рассмотрены ниже:
1. «Обычная работа». Этот сценарий выберет большинство зрелых в вопросах BPM ор-
ганизаций. Предприятия и бизнес-менеджеры полностью стоят на позициях организации,
ориентированной на процессы, и проекты BPM — их обычная повседневная работа или про-
екты.
2. «Рулевой». Данный сценарий случается на следующем уровне зрелости организации в
вопросах BPM. Проектом «рулит» бизнес-менеджер, полностью владеющий информацией и
целиком преданный внедрению BPM в организацию или подразделение, за которое отвечает.
3. «Пилотный проект». Ситуация полностью владеющего информацией бизнес-
менеджера, который еще не совсем убежден в преимуществах BPM, но готов для начала по-
пробовать его осуществление в скромном масштабе.
4. «Вне поля зрения». Этот сценарий случается в наименее зрелых с позиции BPM орга-
низациях. Мало владеющий информацией бизнес-менеджер, пока не убежденный в преиму-
ществах BPM и не очень интересующийся (если интересующийся вообще) вопросом BPM в
организации. Сценарий может оказаться проектом под видом совершенствования процессов,
а BPM может вообще не упоминаться. Интересное наблюдение, связанное с этим типом сце-
нария, состоит в том, что в некоторых организациях может быть реализовано несколько про-
ектов BPM, но не привлекших необходимого внимания соответствующего руководства, что-
бы взяться за широкомасштабное внедрение BPM.
Как выбрать сценарий?!
Сценарий зависит от увлеченности и целеустремленности бизнес-менеджера. В этом
смысле именно бизнес-менеджер, например, генеральный или исполнительный директор
определяет стратегию бизнеса. Чем глубже он вовлечен в проект и сильнее убежден в нем,
тем больше влияния может (и должен) оказать проект на организацию. Это показано на рис.
12.3, где видно, что важно сначала определить степень участия бизнес-менеджера, и лишь
затем целесообразно рассмотреть влияние на организацию. Как только в организации полно-
стью внедрен BPM (т.е. она ориентирована на процессы), все инициативы BPM, и неболь-
шие, и крупные, будут проектами сценария «обычная работа».
Общие характеристики сценариев BPM приведены в табл. 12.1.
Таблица 12.1. Характеристики различных сценариев проекта BPM
Обычная работа Рулевой Пилотный проект Вне поля зре-
ния

Тип BPM ини- Инициатива орга- Программа или Проект или про- Проект
циативы низации инициатива орга- грамма
низации

Опыт в BPM BPM встроено в Несколько Отсутствует / Отсутствует /

организацию успешно реализо- ограничен; воз- ограничен
ванных проектов можно, один-два
BPM или про- успешных проек-
грамм тов BPM

Ступень зрело- Управляемый Повторяемый, Начальный, повто- Начальный

сти организации сформированный, ряемый
в BPM управляемый

Причины / От операционных Стратегические Ряд широких опе- Операцион-

включатели проблем до страте- вопросы, напри- рационных про- ные проблемы
инициативы гических вопросов мер, слияния, со- блем; стратегиче-
BPM ответствие зако- ские вопросы
нодательству
 Обычная работа Рулевой Пилотный проект Вне поля зре-
ния

Количество за- В зависимости от Потенциально Среднее количе- Ограниченное

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

Уровень в орга- Зависит от размера Организация или Бизнес- Отдел, проек-

низации проекта бизнес- подразделение ты
подразделение

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

Пропуск этапа. Настоятельно рекомендуется учитывать все этапы схемы, однако,

встречаются ситуации, когда выполнять все шаги этапа необязательно. В совсем новой орга-
низации может быть пропущен этап понимания. Однако очень редко встречаются ситуации,
когда новое предприятие или направление бизнеса приходится начинать «с нуля» с точки
зрения процессов. Во многих случаях организации уже выполняют предлагаемые процессы в
небольшом масштабе и просто стремятся переместить эту работу в более широкую сферу. В
такой ситуации важно осмыслить накопленный опыт (процессы небольшого масштаба), что-
бы было удобнее формировать нужные процессы на будущее (этап инноваций).
Если организация намерена пропустить этап или шаги этапа, очень важно тщательно
изучить такой ход и его последствия.
Итерационный подход. При первом рассмотрении кажется, что такой подход устремлен
вперед, поскольку перед началом следующего этапа завершается предыдущий. Но при более
внимательном изучении этапа обнаруживаются связи, как с последующим, так и с предыду-
щим, причем два их уровня:
1. уровень проекта. Связи между различными этапами проекта, которые могут выпол-
няться итерационно. Например, между этапами инноваций и разработки могут быть обрат-
ные и прямые связи. На этапе инноваций может быть выбрано решение BPM, которое обес-
печит дополнительные возможности на этапе разработки или не обеспечит всю требуемую
функциональность, что вызовет необходимость возврата на этап инноваций для изучения
ситуации и выбора пути вперед.
В начале каждого этапа мы указываем входную информацию от других этапов, а в конце
соответствующей главы даем основные итоги текущего этапа. Это и есть прямые и обратные
связи между этапами.
2. Уровень организации. Само BPM — тоже процесс. Как будет видно в последующих
главах, ни один процесс не может быть полным без достаточных петель обратной связи,
обеспечивающих «обучение» организации на собственном опыте (рис. 12.4). Например, в
результате осуществления проекта BPM будет получена информация, которая вызовет необ-
ходимость пересмотра стратегии организации и архитектуры процессов. На более детальном
уровне анализ после реализации проекта даст практические выводы, которые будет необхо-
димо учесть в проекте, и которые могут встраиваться в будущие проекты BPM (например,
разработка обоснования на стартовом этапе).
В следующей главе мы приступим к описанию каждого этапа общей схемы.

Глава 13. Этап разработки стратегии

Назначение. Самосогласованность организации — важнейший фактор достижения ею
результатов. Существует множество элементов, которые нужно увязывать или согласовы-
вать. В литературе о BPM ведется широкое обсуждение необходимости увязывать проект
или программу работ BPM со стратегией организации, что вполне справедливо. В данной
главе рассматривается этап выработки стратегии.
Задача состоит в обеспечении четкой связи проектов BPM со стратегией организации, в
которую они должны вносить свой вклад. Очень часто проекты BPM работают в «нишах»
организации, и как будто не имеют никакого отношения к ее стратегии. Однако в каждой ор-
ганизации и в каждом проекте необходимо потратить время на осознание общей стратегии и
обеспечить осязаемый вклад проекта в достижение установленных стратегических целей.
Глубина и охват такого анализа зависит от важности проекта для организации и уровня ру-
ководства, с которым приходится работать по проекту. Если проект не способен продемон-
стрировать пользу для организации и вклад в ее стратегическое направление, его не следует
начинать. Многие проекты оправданы в силу своего тактического характера, однако часто
тактические решения становятся долгосрочными.
Стратегии посвящено множество книг, и существует огромное количество определений
и методологий. Нам близок подход Хамеля и Прахалада (Hamel, Prahalad, [23]), основанный
на понятии стратегического вектора-устремления. Они пишут: «если архитектура стратегии
— это мозг, то стратегическое стремление — это сердце». Стратегическое устремление
наделяет любую организацию тремя качествами:
 1. направленностью — конкретный взгляд и представление о долгосрочной рыночной
или конкурентной позиции, которую организация намерена выстроить в ближайшие лет де-
сять или около того.
2. Познанием — особый непохожий ни на какой другой в смысле конкуренции взгляд в
будущее.
3. Предназначением — придает эмоциональную окраску стратегии и является целью, к
которой внутренне стремятся сотрудники.
В задачу этой главы не входит описание разработки стратегии: этому посвящено много
публикаций. Здесь же мы хотим остановиться на том, как стратегия организации, управление
процессами и отдельно взятые процессы связаны и взаимодействуют друг с другом (рис.
13.1).

Для чего нужна стратегия в BPM?! Процессы — это не самоцель, а лишь средства до-
стижения бизнес-цели. Выбор этой цели и подход к ее достижению и составляют суть стра-
тегии организации. Руководители должны сформулировать цели (целевые ориентиры) орга-
низации и обеспечить, чтобы процессы поддерживали или вносили вклад в достижение це-
лей, как показано на рис. 13.2. Поэтому процессы, увязанные со стратегией и целями, оказы-
ваются наиболее эффективными в их достижении и более устойчивыми в средне- или долго-
срочном плане.

Кейс: живем сегодняшним днем

 Компания по выполнению авиаперевозок решила полностью реорганизовать бизнес гру-
зовых перевозок. Мы начали со встречи со всеми заинтересованными сторонами и вопроса
об их видении стратегии организации. Одна из менеджеров по маркетингу возражала против
такого подхода, утверждая, что все требования к процессам уже определены в запросе ин-
формации (RFI). Однако ее коллеги имели в виду фундаментальные изменения бизнеса —
дальнейшее тесное сотрудничество с разнообразными партнерами, дополнительные продук-
ты и услуги, новые методы платежа и бизнес-модели. Выслушав это, менеджер маркетинга
осознала, что составила информационный запрос лишь на основе текущих проблем бизнес-
процессов и сосредоточилась на срочных текущих требованиях. Если бы дальнейшая работа
велась на основе этого запроса, и процессы были перестроены соответственно, без увязки со
стратегией, они бы устарели еще до внедрения.
Вывод. Потратьте время на размышления, чтобы не потерять его, погрязнув в деталях.
При формулировании стратегии важно учитывать существующие процессы, их слабые и
сильные стороны, возможности и ограничения. Значительная доля неудач в реализации стра-
тегии организации и извлечении предполагаемых выгод вызвана игнорированием влияния
стратегии на бизнес-процессы на этапе формулировки стратегии. Легко разработать страте-
гию изолированно; значительно труднее заставить ее реально работать во всей организации.
Кейс: забытая мелочь. Крупный дистрибьютор продуктов провел стратегическую пе-
реориентацию бизнеса. Менеджеры решили, что нужно увеличить выручку от реализации.
Для этого им нужно было значительно улучшить планирование ресурсов и уровень автома-
тизации в организации. Решение заключалось во внедрении новой системы планирования
ресурсов предприятия и замене всех процессов, чтобы установить новую систему ERP.
Вместо роста количества полученных заказов наблюдалось его резкое падение. Проведя
анализ причин этого, менеджеры осознали, что упустили в стратегическом анализе одну
важную мелочь: процесс доставки был уникален, поскольку это была единственная органи-
зация, доставлявшая заказ в течение суток. Изменив процессы ради внедрения новой систе-
мы, они уже не могли укладываться в эти сроки.
Вывод. Убедитесь в соответствии любого решения об изменении процессов исходному
экономическому обоснованию и стратегии.
Результаты. Конкретные осязаемые результаты этапа выработки стратегии дают значи-
тельный материал на входе следующего этапа - архитектуры процессов - и включают:
1. Документально оформленные версии:
o видения перспективы на длительный срок;
o миссии организации;
o задач;
o стратегического устремления;
o целей;
o стратегии реализации.
2. Контекст или бизнес-модель, которая включает:
o клиентов (по типам и объемам);
o услуги/продукты;
o партнеров;
o ключевые дифференцирующие факторы;
o ресурсы.
3. Ключевые дифференцирующие факторы организации.
Осуществление

На рис. 13.3 показаны шаги, связывающие стратегию организации и проект BPM. Осно-
вательность и длительность каждого выбранного шага меняется в зависимости от проекта и
организации. Важнейшим свойством этих шагов является то, что их, по крайней мере, нужно
иметь в виду при переходе к следующему шагу.
 В главе 12 показано, как момент осуществления данного этапа и его основательность за-
висят от выбранного подхода и сценария:
 при подходе, движимом стратегией, этап выработки стратегии является отправной
точкой и требует значительных усилий и внимания. В случае операционной инициативы
проект лишь адресуется к этапу выработки стратегии, чтобы убедиться в его увязке со стра-
тегией;
 внимание и усилия, уделяемые стратегии организации, нарастают при переходе от
проекта по сценарию «вне поля зрения» к сценариям «пилотный проект» и «рулевой». При
сценарии «обычная работа» это зависит от масштаба связанных с проектом изменений в ор-
ганизации.
Шаг 1. Анализ внешних и внутренних аспектов организации. Организация анализи-
рует внутренние и внешние аспекты. Под внутренними аспектами мы подразумеваем силь-
ные и слабые стороны, компетенции и ограничения организации, а под внешними — воздей-
ствие на организацию конкурентной и окружающей среды. Глубина и степень детальности
анализа зависят от выбранного сценария BPM. В «рулевом» сценарии этот шаг может быть
более детальным, чем в сценарии «вне поля зрения». Полезными моделями для применения
на этом шаге являются:
 анализ ССВУ (сильные/слабые стороны, возможности и угрозы) [58];
 ключевые компетенции [23];
 конкурентные силы [58];
 аспекты окружающей среды [58].
Шаг 2. Выбор стратегических характеристик. После анализа необходимо сделать вы-
бор стратегических характеристик и зафиксировать их. В сценарии «рулевой» чрезвычайно
важно ответить на перечисленные ниже вопросы, при этом ответы должны быть максималь-
но актуализированы. При подходе «вне поля зрения» обычно достаточно иметь четкое по-
нимание большинства из этих вопросов без необходимости полностью переделывать каждый
ответ и увязывать его с проектом BPM.
Ключевые вопросы, требующие максимально актуализированных ответов:
 видение стратегической перспективы: чем организация стремится «стать»;
 миссия: что стремится «делать» организация в бизнесе;
 задачи: что собирается совершить организация;
 стратегическое устремление (вектор стратегии): как мы намерены достичь целей и
показателей;
 цель: каких результатов собирается достичь организация;
 стратегия реализации: какие методы или подходы используются для решения задач и
достижения целевых производственных показателей.
Для ответа на эти вопросы опишем два из наиболее полезных методов, подходящих для
BPM:
1. Триси (Treacy, M.) и Виерсма (Wiersma, F.) [73] считают, что каждая компания долж-
на выбрать одно из стратегических направлений:
 доверительные отношения с клиентом — лучшее комплексное решение для клиента;
 совершенство функционирования — по затратам и себестоимости;
 обеспечение лидирующего положения продукта — продукт должен быть лучшим.
Эти авторы считают невозможным для организации быть лидером по всем трем страте-
гическим направлениям. Организация должна сделать выбор в пользу одного приоритетного
направления, в противном случае она «застрянет посередине» [58] и, в конечном итоге, не
выживет.
С точки зрения процессов это один из основных выборов, влияющих на каждый бизнес-
процесс в отдельности. Под углом зрения проекта BPM абсолютно необходимо получить
четкое понимание направления, которое хочет выбрать организация, потому что этот выбор
сильно скажется на подходе проекта.
Анализ и планирование процессов невозможно, если не сделать этот выбор, потому что
суть процессов заключается в правильном выборе для достижения желаемых результатов
посредством выбранной стратегии. Без четкой формулировки стратегии неясно, как процес-
сы могут способствовать достижению результатов, что приводит к несогласованности выбо-
ров на нижнем уровне управления и, в конечном итоге, к неспособности высшего руковод-
ства направлять процессы, организацию и персонал.
 2. Стратегические карты Каплана и Нортона [37] описывают создание ценности органи-
зацией, связывая стратегические цели (показатели) явными причинно-следственными зави-
симостями через целевые показатели четырех таблиц сбалансированных показателей (фи-
нансы, клиенты, бизнес-процессы, освоение опыта и рост).
Эта модель сильна тем, что использует тот же метод формулирования стратегии (и, в ко-
нечном итоге, оценки ее успеха) - таблицу сбалансированных показателей. Процессы играют
ключевую роль в методе стратегических карт Каплана и Нортона, поскольку обеспечивают
организации возможность реализации целей и являются основой, позволяющей планировать,
действовать, измерять и проверять работу. Слишком часто разработка и мониторинг таблиц
сбалансированных показателей оказываются полностью отделены от процессов, которые
должны обеспечить результат. Это ведет к неэффективности, расплывчатости и несет угрозу
сосредоточиться на неверных элементах. Стратегические карты Каплана и Нортона дают
уверенность, что процессы учитываются при разработке таблиц сбалансированных показате-
лей.
Шаг 3. Определение влияния стратегии на процессы. На этом шаге в общих чертах
анализируется влияние стратегии организации на бизнес-процессы. Этот шаг применим ко
всем четырем упомянутым выше сценариям («обычная работа», «рулевой», «пилотный про-
ект» и «вне поля зрения»). Походящие модели, изложенные в данной главе, применяются
для описания этих воздействий.
Влияние на процессы оказывает не только стратегия организации, но и результаты ана-
лиза (выполняемого на шаге 1), который должен проводиться как часть изучения внутренних
и внешних аспектов организации, а также определение стратегии (шаг 2). Это охватывает:
 стратегический выбор;
 ключевые компетенции;
 конкурентные силы;
 анализ ССВУ (SWOT).
Стратегический выбор должен анализироваться с позиции бизнес-процессов. Важно с
самого начала достичь консенсуса по вопросу выбора стратегических характеристик, по-
скольку только после этого можно достичь согласия в вопросе о процессах, поддерживаю-
щих стратегический выбор. В Приложении А мы привели полезную оценочную опросную
анкету для выяснения стратегических выборов в организации. На рис. 13.4 представлен ре-
зультат такого опроса. Этот пример показывает, что у людей разные взгляды на стратегиче-
ский выбор организации, и ясно, что у генерального менеджера (совершенство функциони-
рования), менеджера колл-центра (доверительные отношения с клиентом) и менеджера по
маркетингу (обеспечение лидирующего положения продукта) представления о стратегии се-
рьезно различаются.

Как только стратегический выбор определен и согласован, можно рассмотреть влияние и

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

Основные про-  Исполнение за-  Приобретения  Разработка

цессы казов  Доставка продукта
 Инжиниринг  Маркетинговые  Технические
процессов коммуникации услуги
 Маркетинго-
вый менеджмент

Организация и  Централизован-  Общее доверие  Высокий уро-

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

Основные пере-  Низкие затраты  Гибкость  Гибкость

менные процес-  Короткий под-  Делегирование  Продукт
сов готовительный срок полномочий сотрудни-
кам

Системы управ-  Взаимоотноше-  Мониторинг по-  Ориентация

ления ния с основными кли- казателей, определяю- на рост продаж и
ентами щих ценности продук- рентабельность
 Оптимизация та/услуги с точки зрения  Особые схе-
затрат клиента (например, за- мы целевых норма-
 Раздельный учет траты на протяжении тивов
затрат по типам дея- жизненного цикла про-
тельности дукта)
 Затраты в ре-  Удовлетворен-
альном времени ность клиента, совмест-
ный менеджмент

Ключевые компетенции [23] — это модель корпоративной стратегии «наизнанку», ко-

торая начинает стратегический процесс с рассмотрения ключевых сильных сторон организа-
ции. Данное представление основано на убеждении, что конкурентоспособность вытекает из
способности производить с более низкими затратами, лучше или быстрее конкурентов осва-
ивать:
1. новые продукты, услуги и рынки. Модульность процессов может обеспечить возмож-
ность создавать новые продукты или услуги быстрее и дешевле, чем другим образом. С уче-
том пристрастия клиентов к усилению персонализации услуг и продуктов способность при-
менять готовые модули процессов и сами процессы дает существенный вклад в конкуренто-
способность организации. К тому же, если в организации существует грамотный процесс
разработки продукта, который вовремя исполняется, вовлекает нужный персонал и интегри-
рует разработку продукта и операционную деятельность, такая организация может разраба-
тывать продукты и услуги лучше и быстрее.
Вариация этого метода — принятие стратегии «разумного перенимания». Это означает,
что организация не проводит прорывных исследований и разработок самостоятельно и не
несет соответствующих расходов и рисков. Вместо этого процессы организуются таким об-
разом, чтобы быстро копировать у конкурентов удачные продукты и услуги.
2. Принципиальный выигрыш клиента. Все процессы должны быть нацелены на обеспе-
чение выигрыша клиента. Это обеспечивается не по мановению руки, а планомерным и со-
гласованным конструированием и исполнением в рамках процессов организации. Не забы-
вайте, что восприятие клиента — штука весьма чувствительная. Нужно вложить много сил,
чтобы создать его, и оно может рухнуть мгновенно, если один или несколько процессов или
работников-участников процесса не соответствует предполагаемому выигрышу. Выигрыш
клиента должен быть определен с самого начала, и на каждом шаге необходимо оценивать
его вклад в общий результат.
3. Уникальная конкурентная особенность. В идеале все основные процессы и связанные
с ними процессы обеспечения должны включать некоторые конкурентоспособные составля-
ющие. Получить конкурентное преимущество очень тяжело, но еще труднее его сохранять.
Для этого требуется, чтобы все процессы (в т.ч. основные и обеспечивающие) были «заточе-
ны» на поддержание конкурентного превосходства и брали в расчет тенденции рынка, кон-
курентов и замены продуктов на постоянной основе. Анализ и сохранение этого конкурент-
ного преимущества может предусматривать переход на другую модель бизнеса, других кли-
ентов, добавление новых продуктов или услуг.
Кейс: маневренность как стратегия
Организация связи пересматривала свою стратегию и анализировала цепочку создания
ценности. Однако это не выявило каких-либо серьезных отличительных характеристик и не
дало стратегических идей. Анализируя сильные и слабые стороны организации, менеджеры
поняли, что одним из наиболее ярких преимуществ была способность быстро выводить на
рынок новые продукты и услуги. В результате стержнем стратегии выбрали маневренность и
решили использовать подход «разумного перенимания»: организация не пыталась оставаться
на переднем крае инноваций на своем рынке, но инновационные прорывы быстро заимство-
вались и распространялись.
Вывод. Правильный выбор стратегии сделать легче, и он, вероятно, окажется эффектив-
ным, если организации осознает свои сильные стороны. Их увязка с процессами может стать
источником конкурентного преимущества.
Конкурентные силы. Очень важно понять, что в каждом из пяти аспектов анализа кон-
курентных сил, предложенных Майклом Портером (выход на рынок конкурентов, угрозы
замены, способность покупателей торговаться, способность поставщиков торговаться и со-
перничество между существующими игроками), имеется составляющая процесса. Способ-
ность поставщика торговаться может быть снижена, если внедрены общие процессы взаимо-
действия с поставщиками. Способность покупателей торговаться также можно снизить, если
продающая организация смогла «пленить клиента» с помощью особо настроенных процес-
сов.
Эти силы очень полезны при рассмотрении различных стратегических сценариев типа
«что, если…» и последующей оценки их воздействия на процессы в организации (например,
какое влияние окажет на процессы усиление конкуренции или появление на рынке новых
продуктов, или что произойдет с изменением законодательства). Если не понять и не «про-
играть» эти сценарии, может случиться, что при смене обстоятельств, придется срочно ме-
нять стратегию, или могут потребоваться дорогостоящие изменения процессов. Поэтому
группа управления процессами должна четко понимать, какие процессы наиболее вероятно
придется изменять. Такое понимание даст возможность менеджерам процессов оценить объ-
ем ресурсов, прилагаемых для обеспечения гибкости и маневренности процессов.
Кейс: анализ «что если…» Организация связи предполагала открыть новое бизнес-
подразделение для особого сегмента рынка. В исходном предложении менеджеры утвержда-
ли, что им нужен единый тип процесса выставления счетов, а гибкость не требовалась: важ-
ны были сроки выхода на рынок. В тот же день, анализируя требования, мы задали много
вопросов типа «а что если … ». Вскоре менеджерам стало ясно, что организации нужна гиб-
кость процессов выставления счетов для различия клиентов в секторах населения и предпри-
ятий. Нам удалось сформировать такие процессы выставления счетов лишь не намного
дольше, чем планировалось изначально, но эти процессы отвечали требованиям бизнеса не
только на начальной стадии, но и на многих последующих. Организация была нам чрезвы-
чайно благодарна, поскольку менеджеры пришли к правильному пониманию, что сэкономи-
ло им много времени и средств (иначе пришлось бы через год менять изначально задуман-
ную систему выставления счетов) за счет небольшого увеличения сроков, потребовавшегося
для проведения анализа типа «что если … ».
Вывод. Мыслите шире, задавая множество вопросов типа «что если …».
 SWOT-анализ бизнес-процессов может выявить, что некоторые из них являются выра-
женным «слабым местом», а другие представляют сильную сторону. Это будет иметь серь-
езные последствия для бизнес-модели организации: например, откроет возможность сделать
процессы, определяющие силу организации, основными. Они могут обеспечить стратегиче-
ские возможности организации (например, «инсорсинг»), самостоятельное выполнение и
управление процессами. В то же время можно подумать об аутсорсинге процессов, оказав-
шихся слабой стороной. Если, например, слабое звено — процесс в ИТ службе поддержки
клиентов, то организация может отказаться от него, сосредоточив весь потенциал и ресурсы
на отлаженных процессах. Какой бы вариант ни был избран, бизнес-модель изменится.
Призма производительности / эффективности [50] — это методика измерения и
управления показателями функционирования, в которой все заинтересованные стороны рас-
сматриваются в контексте двусторонних отношений: с одной стороны — чего хотят заинте-
ресованные стороны, и что им нужно, с другой стороны — чего хочет сама организация, и
что ей нужно от заинтересованных сторон. У призмы пять граней:
 удовлетворение заинтересованных сторон;
 вклад заинтересованных сторон;
 стратегии;
 процессы;
 возможности.
Некоторые из значимых вопросов, требующих рассмотрения:
 какие важнейшие процессы необходимы для реализации данной стратегии;
 какие функциональные возможности необходимы для работы и расширения этих
процессов;
 что нужно получить от заинтересованных сторон, чтобы поддерживать и развивать
такие функциональные возможности.
Данная методика позволяет вписать заинтересованных лиц в общую картину и связать
их с бизнес-процессами. Если они не вписаны в общий ряд, это может привести к получению
процессов, не отвечающих требованиям заинтересованных сторон, что потребует непредви-
денных изменений, которые к тому же могут оказаться дорогостоящими и трудными в реа-
лизации.
Шаг 4. Определение стратегических показателей
На этом шаге определяются крупные показатели, обеспечивающие организации способ-
ность:
 измерять и осуществлять мониторинг реализации стратегии;
 задать более точные и персональные нормативы, начиная со среднего звена и закан-
чивая уровнем исполнителей;
 оценивать инициативы и проекты по их вкладу и пользе для установленных стратеги-
ческих показателей.
Система сбалансированных показателей (BSC) [36] дает возможность количественно
выразить целевые показатели организации в увязке со стратегией и видением перспективы.
Упомянутые выше стратегические карты можно напрямую связать с таблицей сбалансиро-
ванных показателей. Рассматриваются четыре перспективные проекции:
 финансовая перспективная проекция;
 перспективная проекция клиентов;
 перспективная проекция бизнес-процессов;
 перспективная проекция освоения (обучения) и роста.
Для каждой из них определяются четыре характеристики:
 цели;
 показатели;
 целевые нормативы;
 инициативные действия.
Система сбалансированных показателей — прекрасный способ определить цели органи-
зации на верхнем уровне и обеспечить выдачу совокупного итогового результата опорными
процессами и подразделениями, отвечающего этим поставленным целям.
Четыре проекции Системы сбалансированных показателей позволяют включить в рас-
смотрение краткосрочные выгоды и более фундаментальные последствия. Как уже подчер-
кивалось, весьма важно увязать это с бизнес-процессами, а также важно, чтобы бизнес - про-
цессы давали картину в реальном времени динамики характеристик Системы сбалансиро-
ванных показателей.
Шаг 5. Разработка плана
Стратегия и ключевые решения должны быть изложены в документе — стратегическом
плане, содержащем общие цели предприятия, а также выбор основных стратегических
направлений, которые рассматривались на предыдущих шагах этапа. Помните, что стратегия
заключается не просто в определении целей — она должна давать и общее руководство по
их достижению организацией.
Мы прибегнем к структуре (рис. 13.5), являющейся основой для архитектуры процессов,
которая разрабатывается на втором этапе схемы. Наряду с общими принципами стратегиче-
ский план должен содержать и план действий.

Стратегические цели стоят перед организацией или подразделением и обычно уже

сформулированы организацией, например «увеличение оборота на 10%».
Стратегические принципы (выбор стратегических характеристик) выводятся из ви-
дения перспективы и стратегии организации и образуют стратегический уровень ее архитек-
туры процессов. Они должны быть сформулированы просто и доступно для понимания все-
ми сотрудниками, например:
 «организация идет по стратегическому пути совершенства функционирования (это
принимается в расчет при оценке существующих процессов и планировании но-
вых/перепланировании процессов)»;
 «у клиента есть единая точка соприкосновения по всем вопросам (все процессы опи-
сываются как сквозные)».
Шаг 6. Утверждение и распространение результатов
И, наконец, очень важно получить формальное утверждение итогов и результатов
предыдущих шагов, а также довести их до всех заинтересованных сторон. Утверждение ре-
зультатов — завершающий шаг, потому все решения должны быть оформлены официально.
Чем сильнее влияние проекта на организацию (как в сценарии «рулевой»), тем критич-
нее добиться убежденности и реального содействия проекту, а не просто поддержки на сло-
вах, от всех заинтересованных сторон. В сценариях, где влияние на организацию ограничено
(например, «вне поля зрения»), утверждение — это просто формальная проверка того, что
вся нужная информация получена и предоставлена в распоряжение соответствующих лиц.
С момента утверждения итогов необходим строгий подход к управлению изменениями в
стратегии организации, как к любым изменениям объема проекта.
Распространение стратегии организации и результатов ее влияния на бизнес-процессы,
доведение их до людей также чрезвычайно важно, поскольку позволяет разблокировать те-
кущую ситуацию и сдвинуть организацию с мертвой точки в стратегическом направлении.
Этап выработки стратегии — фундамент любого проекта или программы BPM, дающий
«смысл существования» (raison d’être), мотивирующий и направляющий участников проекта
и людей в организации.
Итоги этапа разработки стратегии
Конкретные результаты этапа выработки стратегии (рис. 13.6) дают важные входные
данные для других этапов проекта:
  при создании архитектуры процессов организации необходимо понимание целей и
задач, сформулированных в стратегии;
 при определении объема проекта и разработке исходного экономического обоснова-
ния группа проекта должна обеспечить вклад проекта в достижение целей и задач организа-
ции;
 результаты этого этапа должны быть представлены и приняты во внимание на этапе
инноваций, поскольку именно на нем будут разработаны новые процессы, которые должны
питаться стратегией организации и увязываться с ней.
Фактически на всех этапах проекта необходимо использовать и четко понимать резуль-
таты этапа выработки стратегии, чтобы обеспечить реальный вклад каждого шага проекта в
достижение целей организации.
Риски этапа разработки стратегии
Несколько наиболее часто встречающихся рисков этапа выработки стратегии приведены
в табл. 13.2.
Таблица 13.2. Риски этапа выработки стратегии и пути их снижения
Риск Пути снижения риска

Новая формулировка стратегии организации С самого начала четко остановите

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

Бесконечное ожидание информации о стратегии Если информация не выдается сразу,

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

Нет убежденности высшего руководства Начните мелкие улучшения и полу-

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

Глава 14. Этап архитектуры процессов

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

Назначение
Архитектура процессов — важнейшая ступень проекта и организации BPM, но слишком
часто ею пренебрегают или поддерживают ее лишь на словах. Архитектура процессов долж-
на обеспечить:
 соответствие перестроенных или вновь разработанных процессов целям организации,
и ее стратегии;
 увязывание процессов с тем, как ведется (или должен вестись) бизнес и способность
предоставить продукты/услуги потребителям;
 увязывание процессов с архитектурой ИТ и приложениями, поскольку ИТ должны
поддерживать настоящие и будущие процессы;
 согласование одних процессов с другими. В больших организациях часто ведется не-
сколько инициатив управления процессами одновременно, и чрезвычайно важно, чтобы они
были согласованы;
 группировку всей связанной с процессами информации и принимаемых по ним реше-
ний. Если информация разбросана по всей организации, это может привести к дублирова-
нию, путанице и несогласованности;
 представление относящихся к процессам решений и процессов высокого уровня про-
стым и понятным образом. Правильно выстроенная архитектура оценивается исключительно
по ее полезности, а не по тому, насколько она сложна или привлекательна.
 Кейс: неуклонно реализовывать стратегию
Мы оценивали процессы в организации, стремившейся радикально повысить свою долю
на рынке за счет «практичности и экономичности» (что эквивалентно стратегии функцио-
нального совершенствования). При рассмотрении процессов центра обработки вызовов мы
заметили, что процессы не отвечают данной стратегии. Эти процессы были весьма сложны-
ми и, скорее, соответствовали стратегии выстраивания доверительных отношений с клиен-
тами. Менеджер колл-центра стремился обеспечить положительный опыт взаимодействия с
клиентами, а «экономичность и практичность» были на втором плане. Высшее руководство
было удивлено, что такое несоответствие интерпретации оставалось незамеченным столь
долго и не только изменило работу центра вызовов в сторону «практичности и экономично-
сти», но и инициировало общее формирование архитектуры бизнеса, чтобы обеспечить учет
стратегических соображений всей организацией при анализе и перекраивании процессов.
Вывод. Обеспечьте явную формулировку стратегии, и ее применение при конструиро-
вании и мониторинге процессов. Архитектура процессов — хороший способ добиться этого.
Нам часто приходилось наблюдать архитектуру процессов, выстроенную в результате
затянутого анализа и планирования. Полученные в итоге подробные модели страдали двумя
основными недостатками: они были слишком сложными и, что более важно, всегда немного
запаздывали. Таким образом, в подобной ситуации архитектура процессов фиксировала
прошлое, а не описывала текущую ситуацию с указанием пути в будущее. Оба недостатка
приводили к тому, что архитектура процессов становилась в большой мере хобби несколь-
ких лиц с лучшими намерениями, и не использовалась во всей организации.
Кейс: 1 + 1 + 1 = 1 Крупная организация решила отладить внутренние процессы. Отдел
ИТ наложил на свою деятельность процессы, которые нужно было поддерживать, используя
инструмент моделирования «1» и ИТ-подход. Бизнес-подразделение описало процессы с по-
мощью инструмента моделирования «2» и действовало методами, соответствующими этому
инструменту. Финансовое подразделение стремилось отобразить процессы, имеющие фи-
нансовое воздействие, в целях соблюдения закона Сарбанеса-Оксли, используя еще один ин-
струмент моделирования. Очевидно, что при таком подходе нельзя получить существенных
и долгосрочных результатов:
 у каждого структурного подразделения будет лишь частичное видение процессов ор-
ганизации;
 нет никакой увязки между различными моделями;
 сомнительно, чтобы описания процессов поддерживались со временем;
 стоимость поддержки будет очень высока.
Вывод. Несогласованный фрагментарный подход к моделированию процессов и управ-
лению ведет к фрагментарному применению, вызывая высокие затраты, разочарование и
ограниченность ценности.
В этой книге описана архитектура, которая комплексна и понятна (дает внутреннюю
картину сложного объекта), а также динамична (учитывает изменения бизнеса). Короче го-
воря, архитектура должна быть строго достаточна и строго своевременна.
Архитектура процессов может работать, только если, во-первых, она увязана со страте-
гией и стратегическими целями организации, а во-вторых, увязана с архитектурой бизнеса,
организации и ИТ.
И, наконец, архитектура должна экономить больше, чем стоит ее разработка и содержа-
ние. Слишком часто увлеченные люди тратят бесконечно много энергии и усилий на архи-
тектуру, которой никто не пользуется. Единственный путь эффективно разработать и под-
держивать динамичную архитектуру — это сформировать архитектурный процесс, преду-
сматривающий учет всех механизмов включения, факторов и политик при разработке и реа-
лизации архитектуры.
Но в отношении архитектуры справедлива одна суровая истина [52]: … динамика орга-
низации и культура всегда побеждают архитектуру. Без общего понимания цели и миссии,
без эффективной руководящей структуры, ведущей роли и нацеленности руководства от
архитектуры предприятия будет мало толку. Хорошая архитектура предприятия — это
инструмент руководящего состава в деле повышения эффективности и маневренности
предприятия и сопряжения (с бизнесом).
В центре внимания данной главы — архитектура процессов, но многие положения, от-
носящиеся к этому этапу, также применимы и к архитектуре предприятия.
 Что такое архитектура процессов? Говорят, что если спросить десять архитекторов, то
можно получить десять разных определений архитектуры. Поэтому, чтобы не придумывать
свое определение, мы перечислим характеристики, составляющие хорошую архитектуру
(Вагтер и др. [77]):
 должен быть комплекс правил, принципов и моделей процессов;
 должна быть основа для разработки и внедрения процессов организации;
 процессы должны соотноситься со стратегией организации и стратегическими целя-
ми;
 процессы должны быть увязаны с архитектурой бизнеса, информационной и техниче-
ской архитектурой, что сводится к организационно-движимой архитектуре предприятия;
 процессы должны быть легко понимаемы и применимы всеми заинтересованными
лицами;
 архитектура процессов должна быть динамичной, легко адаптируемой к возникаю-
щим изменениям процессов, бизнеса и предприятия.
Нам приходилось изучать различные архитектуры процессов, и мы пришли к выводу,
что показанная на рис. 14.2 модель лучше всего соответствует перечисленным характери-
стикам.

Методическое руководство по процессам — это отображение общих принципов на об-

ласть процессов. Примерами методических руководств по процессам являются стандарты,
методы, инструкции, политика и выбор инструментария. Руководство должно давать кон-
кретные указания по разработке процессов (и последующим разработкам ИТ), и имеет так-
тическое значение (например, конструкция бизнес-процессов выполняется независимо от
структуры организации).
 Модели процессов — это визуальное представление процессов общего уровня, а также
общих взаимосвязей между процессами. Пирамида под архитектурой показывает, как более
подробные модели процессов укладываются в эту архитектуру. Такие модели строятся на
дальнейших этапах.
Архитектурные принципы
Мы следуем таким архитектурным принципам [77]:
 архитектура не является самоцелью, а должна поддерживать цели бизнеса;
 архитектура — это больше, чем модели и документация; она работает с логикой, ко-
торая формирует основу моделей и документации;
 есть единственный способ добиться динамичной архитектуры в курсе стратегии и
бизнеса — архитектурный процесс, который работает со всеми механизмами включения и
последующими изменениями;
 архитектуру можно развивать, постоянно наращивая ее;
 в некоторых обстоятельствах оправданно несоблюдение архитектуры; мы называем
это «клапаном скороварки» и рассматриваем на шаге 6 ниже.
Результаты. Перечислим конкретные результаты на выходе этого этапа:
1. документально оформленная и согласованная архитектура процессов.
2. Стартовая структура проекта.
3. Картина процессов организации.
4. Перечень сквозных процессов.
Осуществление. В фокусе этапа архитектуры процессов, как и на этапе стратегии орга-
низации, находятся организационные аспекты проекта BPM. При осуществлении данного
этапа нужно иметь в виду следующую информацию:
1. Сценарий проекта BPM (см. выше). Выбранный организацией сценарий BPM оказы-
вает серьезное влияние на интенсивность и критичность этого этапа:
o сценарий «обычная работа»: оценивается доступная смысловая информация
(используя стартовую структуру проекта ССП — см. ниже), а любые изменения вносятся по-
средством соответствующих каналов управления изменениями. Это может приводить к из-
менениям в архитектуре процессов — можно разрешить управляемые и частичные исключе-
ния;
o сценарий «рулевой»: оценивается имеющаяся информация, и архитектура про-
цессов либо исправляется, либо вновь разрабатывается, если данный проект BPM — первый
для организации;
o сценарий «пилотного проекта»: оценивается имеющаяся информация, могут
задаваться вопросы в целях ее уточнения. Помимо этого изучается архитектура процессов,
могут предлагаться требуемые изменения. Объем этих изменений ограничен;
o сценарий «вне поля зрения»: имеющаяся информация оценивается. Возможно,
возникнут уточняющие вопросы. Документация архитектуры процессов не исправляется или
исправляется очень ограниченно.
2. Зрелость организации в области архитектуры процессов. Понятие «зрелости» орга-
низации относится не только к уровню архитектурного «мышления» и реализации, но и к
способности соответствующих архитектурных «действий», а также привычке подчиняться
данному порядку (рис. 14.3):
 o изоляция относится к ситуации, когда архитекторы разработали безукоризнен-
ную архитектуру в «башне слоновой кости», так что совсем мало народу внутри организации
знает об архитектуре, не говоря уже о ее применении. В такой ситуации архитекторы долж-
ны найти пути вовлечь и убедить остальную часть организации следовать архитектуре;
o барьер относится к обстоятельствам, когда у архитекторов есть необходимая
убежденность остальной части организации, но их архитектура не очень развита. Это озна-
чает, что она в основном остается на операционном уровне, поскольку слишком разрознена,
чтобы вносить более серьезный вклад на стратегическом уровне. Организация должна
встраивать архитектуру в свою стратегию;
o проигрыш относится к ситуации, когда организация слабо отдает себе отчет в
архитектуре, лишь частично интегрированной в организацию. Это встречается в организаци-
ях, где все настолько поглощены решением сиюминутных проблем, что нет времени поду-
мать о тактических и стратегических вариантах более высокого уровня. Мы рекомендуем
начать постепенное распространение архитектуры, чтобы справиться с подобной ситуацией;
o практичность относится к ситуации, когда организация приняла концепцию
архитектуры в качестве главного вспомогательного средства. Важная проблема здесь —
оставить архитектуру рычагом улучшений, а не превратить ее в обузу.
2. Сфера и нацеленность архитектуры. Перед тем как сформулировать архитектуру,
важно определиться с уровнем «амбициозности», т.е. решить, что войдет в сферу архитекту-
ры и будет в ее фокусе. Одно из ключевых решений, принимаемых здесь, начать ли только с
архитектуры процессов (обычно в сценариях «вне поля зрения» и «пилотный проект»), или
моделировать всю архитектуру предприятия (обычно в сценарии «рулевой»).
Еще один важный выбор относится к процессам, которые попадают в сферу архитекту-
ры. Слишком узкий охват ведет к ограниченным выигрышам, а «раздутая» сфера вызывает
увеличение объема работ и снижение выигрыша.
Показанные на рис. 14.4 шаги применяются в создании архитектуры процессов и рас-
сматриваются ниже.

Шаг 1. Получение информации о стратегии и бизнесе

На рис. 14.5 показаны соответствующие продукты/услуги, а также и методические руко-
водства и модели, используемые для получения информации о стратегии и бизнесе.
 Информация, которую необходимо получить:
 общие стратегические цели (показатели) и принципы, определенные на этапе страте-
гии организации, доработанные/обновленные при необходимости;
 соответствующие методические руководства (инструкции) по бизнесу (продукты и
услуги) и модели;
 соответствующие модели и руководства организации.
Уже заявлено, что архитектура процессов работает на бизнес, поэтому так важно пони-
мать основы функционирования бизнеса, что облегчит выработку решений, которые укла-
дываются в логику бизнеса. На этапе стратегии организации уже были получены некоторые
общие принципы. Но архитектура процессов должна также «ухватить» и более неявные
предположения и инструкции, которые в стратегии принимаются как должное. Поэтому
нужно определиться с общими принципами.
Важно прийти к явному соглашению внутри компании по общим принципам: положени-
ям и аспектам, которые являются либо частью стратегии, либо частью более глубоко лежа-
щих неявных предположений и основополагающих принципов внутри организации. По-
скольку это неписаные допущения и принципы, то всегда есть опасность, что они могут быть
забыты или проигнорированы, или что у соответствующих сотрудников будут различные
взгляды на них. Лучше всего сформулировать эти предположения на практических совеща-
ниях с участием вовлеченного в них персонала. Чрезвычайно важно получить четко опреде-
ленную и согласованную на широкой основе формулировку этих предположений и принци-
пов.
Необходимо извлечь информацию, в основном, общего характера, относящуюся к таким
аспектам, как, например:
 типология продуктов и услуг, опорные принципы и логика;
  типология клиентов, опорные принципы и логика;
 типы расценок и скидок, опорные принципы и логика;
 типы партнеров (включая поставщиков) и каналов распределения, опорные принципы
и логика.
Наш опыт свидетельствует, что получение этой информации может стать серьезной про-
блемой. Хотя большинство сведений имеется под рукой, например перечни продуктов, кли-
ентов и партнеров, проблема обычно заключается в извлечении принципов и логики, потому
что они большей частью являются неявными положениями, которые бизнес принимает во
внимание, что дает еще одно веское основание для создания архитектуры, где неявные сооб-
ражения становятся явными.
Предлагаются следующие способы получения этой информации:
 получение перечней продуктов, клиентов, партнеров и прайс-листов;
 получение годовых финансовых планов, маркетинговых планов, планов по основным
клиентам и бюджетов;
 обсуждения с бизнес-менеджерами причин, по которым они выбрали именно эти про-
дукты, цены, клиентов и партнеров, и почему не включены другие (вопросы «почему?»);
 визуализация структур (например, как конструируется продукт, каждый ли клиент
получает свой индивидуальный продукт, или решение для клиента составляется из стан-
дартных готовых элементов).
Не пытайтесь смоделировать все исключения, помните, что модель — лишь упрощение
реальности, а не полная теория, которая должна объяснять все. Организации, у которых нет
ясной архитектуры бизнеса, часто принимают решения, которые трудно вписать в одну ком-
плексную и понятную архитектуру. Большинство бизнес-менеджеров и менеджеров по про-
дажам выдают решения по-разному, и это еще одно веское основание начать с архитектуры
бизнеса.
Шаг 2. Получение методических указаний и моделей процессов

На шаге 2 (рис. 14.6) должны быть определены следующие моменты:

 методические руководства (инструкции) по процессам;
 модели процессов;
 перечень сквозных процессов.
Кейс: крайний случай правила 80/20
 Компания по производству программного обеспечения испытывала трудности в доведе-
нии до своих клиентов принципов обслуживания, которых она придерживалась при оказании
сервисных услуг. Бизнес-архитектору потребовалось свыше пятидесяти страниц, чтобы опи-
сать основные процессы этого решения, так что никто не имел о нем четкого представления.
Нам удалось дать общую картину 95% основных процессов на трех простых диаграммах и
четырех страницах текста (т.е. менее 10% исходного текста). Когда мы побеседовали с биз-
нес-архитектором, он указал, что не были описаны некоторые исключения. Однако бизнес-
подразделение пришло в восторг от того, что могло легко объяснить структуру своего про-
дукта. С исключениями поработали в других формах.
Вывод. Плоха или хороша архитектура, зависит, в основном, от того, используется ли
она фактически. Поэтому сжатая и простая архитектура процессов может оказаться значи-
тельно лучше сложной новейшей архитектуры.
Методическое руководство по процессам — это общие методические указания, кото-
рые необходимо сформулировать для процессов. Они включают:
1. принадлежность процесса (кто хозяин).
2. Масштаб процессов: сквозные или относящиеся к функции/организационной едини-
це.
3. Выбор метода моделирования.
4. Выбор инструмента моделирования и управления процессов.
5. Метод руководства процессами.
6. Аутсорсинг процессов, т.е. когда организация принимает решение об аутсорсинге
процессов. Если такое решение принято, важно определить:
o тип процессов, которые будут переданы на аутсорсинг (с обоснованием при-
чин);
o тип процессов, которые не будут переданы на аутсорсинг (с обоснованием
причин);
o минимальные критерии, которые должны быть выполнены (например, без-
опасность, соглашения об уровне обслуживания — SLA);
o что еще нужно принять во внимание (например, привлеченный персонал).
7. Эталонные модели процессов: архитектура процессов должна содержать набор шаб-
лонов — эталонных моделей. Эти модели дают мощную базу, поскольку основаны на
наилучших практических методиках (например, ITIL — Библиотека инфраструктур инфор-
мационных технологий, см. сайт www.itil.org.uk) или отраслевой практике (например, eTOM
— расширенная модель функционирования оператора связи, разработанная Форумом управ-
ления электросвязью, — см. сайт www.tmforum.org — или SCOR — эталонная модель це-
почки поставок, разработанная Советом цепочки поставок, — см. www.supply-chain.org).
Кейс: eTOM. Организация связи хотела плотно поработать с компанией из другой стра-
ны. Они провели многие месяцы в переговорах об интеграции соответствующих процессов,
но все усилия были напрасны. Казалось, не было продвижения к решению; всякий раз, когда
решалась одна проблема, появлялась новая проблема или даже пара. Когда мы подключи-
лись, стало ясно, что у обеих организаций различные системы, процессы, бизнес, клиенты и
даже различные определения типов деятельности. Чтобы прийти к пониманию и согласию
по процессам и связанным с ними определениям, мы использовали модель eTOM (расши-
ренная схема деятельности оператора связи), которая позволяла четко установить точки сты-
ка между организациями. Это дало нам возможность завершить работу в несколько недель,
предоставив приемлемое и устойчивое решение.
Вывод. Общее понимание — основа для результативности и продвижения. Эталонные
модели и архитектура процессов жизненно важны в этом аспекте.
Модели процессов. Архитектура процессов также должна содержать общее графиче-
ское представление процессов. Хороший способ получить такую визуализацию — составить
диаграмму картины процессов организации и перечень сквозных процессов.
 На рис. 14.7 дается картина процессов организации и более подробный перечень сквоз-
ных процессов.
Картина процессов организации — самый общий вид структуры организации с точки
зрения процессов. На рис. 14.7 приведен пример страховой фирмы. Выделение или группи-
ровка процессов обычно показываются на трех уровнях:
1. стратегические процессы — обеспечивают постоянное выполнение нижележащими
процессами своих задач/показателей.
2. Опорные процессы — представляют основные (главные) области бизнес - деятельно-
сти организации.
3. Вспомогательные процессы (обеспечения/поддержки). На этом уровне находятся
процессы, которые обеспечивают опорные процессы организации.
Диаграмма картины процессов служит нескольким целям:
 используется для описания процессов организации штатному персоналу и заинтере-
сованным лицам;
 ее следует поместить на самом видном месте во всей организации и, возможно, на
внутреннем портале (некоторые организации используют эту диаграмму как домашнюю
страницу внутреннего сайта);
 способствует достижению понимания высшим руководством, должностными лицами
и персоналом основной деятельности, операций и приоритетов организации с точки зрения
процессов, обеспечивая нацеленность на BPM внутри организации.
Однако все это работает, когда общая картина содержит сущностную информацию, при-
нята и используется по всей организации.
Преимущество получения картины процессов в том, что это не только общая модель
уровня организации, которую можно применять для увязки процессов нижних уровней. Она
также позволяет вовлекать в моделирование руководство. Это дает менеджерам организа-
ции возможность сформулировать критически важные зоны процессов, на которых они захо-
тят сконцентрироваться, а также содействует тому, что все основные высшие руководители,
заинтересованные лица и участники проекта BPM говорят на одном языке.
Перечень сквозных процессов. Для каждой из групп, выделенных на картине процес-
сов организации, нужно сформировать перечень сквозных процессов. На этапах понимания и
инноваций каждый сквозной процесс из этого списка описывается более подробно (и назы-
вается моделью сквозного процесса и подробной моделью процесса).
Лучше получить эту информацию на практическом совещании, типовая повестка и под-
ход которого приводятся в Приложении Е.
При разработке этих моделей очень полезно уловить различные метрики, связанные с
бизнес-подразделением организации и процессами, — например, определить число работни-
ков, занятых в каждом процессе или группе процессов, соответствующий объем продаж и
обслуживающих транзакций и т.п. Это поможет сориентировать группу процессов в выборе
процессов или участков бизнеса для начала таких последующих этапов схемы, как понима-
ние и инновации.
Шаг 3. Получение нужной информации, принципов и моделей технологий
На данном шаге нужно получить подробные сведения по необходимым «информацион-
ным» аспектам (которые относятся к данным и приложениям), а также по аспектам «под-
держивающих» технологий (промежуточное ПО, платформы и сети) — рис. 14.8. Мы имеем
в виду общие обзоры:
 моделей данных, их опорных принципов и логики;
 основных приложений и соответствующих интерфейсов, их опорных принципов и ло-
гики;
 основного промежуточного ПО, его опорных принципов и логики;
 основных платформ, их опорных принципов и логики;
 основных сетей, их опорных принципов и логики.

Наш опыт подсказывает, что самая крупная проблема встраивания архитектуры ИТ в ар-
хитектуру предприятия — наличие в подразделении ИТ большинства организаций огромно-
го числа инструментов и приложений. Поэтому нужно суметь сосредоточиться на принципах
и основных вариантах выбора.
Кейс: «неправильная» архитектура
Подразделение ИТ одной организации решило внедрить архитектуру предприятия и вы-
дало ее в виде более чем семидесятистраничного технического описания. Когда им задали
вопрос о следующих шагах, они сказали, что хотят, чтобы высшее руководство утвердило и
в приказном порядке ввело эту «архитектуру». Однако им пришлось признать, что руковод-
ство вряд ли разберется в таком документе, не говоря уже о его утверждении. Они осознали,
что нужно разработать архитектуру принципиально иным способом: скорее продвигаемую
бизнесом, чем наоборот. Разработчики поставили бизнес во главу угла, что привело к созда-
нию полноценной и принятой организацией архитектуры.
Вывод. Крупная проблема архитектуры процессов состоит не в ее формулировании, а в
том, чтобы добиться убежденности людей, которые сами захотят использовать такую архи-
тектуру.
Более того, существенно, что ИТ поддерживают цели, стратегию и бизнес, и именно по-
этому целесообразно уже иметь архитектуру процессов и бизнеса до выстраивания архитек-
туры ИТ. Но если разработка архитектуры началась с архитектуры ИТ, нужно внимательно
следить за сохранением поддерживающей роли ИТ для требований бизнеса.
Шаг 4. Консолидация и сверка
На этом шаге вся информация консолидируется и сверяется. Часто данный шаг оказыва-
ется наиболее проблемным, потому что именно здесь сходятся все противоречивые приори-
теты и требования, и именно здесь все они должны быть разрешены. Например, бизнесу мо-
жет быть нужна гибкость, а подразделению ИТ — стандарты и единообразие.
Один из способов консолидации накопленной информации — сопоставить различные
архитектурные модели друг с другом. Например, сочетание организационно-структурных
схем и процессов дает карту-схему организационных взаимосвязей (рис. 14.9).

Схема организационных взаимосвязей

Схема организационных взаимосвязей, приведенная на рис. 14.9, в общем виде показы-
вает взаимосвязи и протекание процессов между различными подразделениями и отделами
внутри организации. Такая схема дает организации возможность увидеть нестыковки в ходе
выполнения процессов. В этом разрезе особенно полезна картина возможного распределения
сквозных «клиентских» процессов по структуре организации, что может быть причиной за-
держек и ошибок. Светло-серый прямоугольник на рисунке представляет организацию, а
все, что не попадает в него, приходит извне организации.
Пример нестыковки процесса также приведен на рис. 14.9. Центр обработки вызовов ре-
ализует и вырабатывает руководящие инструкции по кредитованию для организации, отдел
взыскания занимается сбором неоплаченных в срок сумм. На этом рисунке нет обратной свя-
зи между деятельностью отдела по взыскиванию сумм (нет такого отдела на схеме – С.К.)
относительно эффективности методических инструкций и центром обработки вызовов (нет
такого отдела на схеме, м.б. колл-центр? – С.К.), чтобы при необходимости подправлять
правила кредитования. Если инструкции по кредитованию неудачны, центр обработки вызо-
вов не получит обратной связи.
Лучший способ выработать такую схему — провести практическое совещание со всеми
заинтересованными сторонами, при этом:
 используя цели и стратегию организации в качестве отправной точки;
 внося все разнообразные требования и взгляды заинтересованных сторон;
 выявляя взаимосвязи и противоречия между этими требованиями;
 обсуждая противоречия и находя пути их разрешения; здесь проблема — снова выйти
из замкнутого пространства мышления и набраться смелости, чтобы принимать решения с
мыслью о будущем, вместо того чтобы застрять в настоящем;
 ранжируя требования;
 обсуждая разрывы в процессах и конфликты (включая пути эскалирования на более
высокие уровни полномочий);
 подготавливая планы мероприятий для устранения нестыковок и противоречий
(включая пути эскалирования);
 предоставляя окончательные выводы соответствующим руководителям, четко обо-
значив связь со стратегией и целями организации и указывая, как сформулированная архи-
тектура будет содействовать их осуществлению;
 добиваясь окончательного утверждения.
Шаг 5. Обмен информацией
Как уже говорилось, хорошая архитектура — это архитектура, которая понимается, под-
держивается и применяется в качестве основы для деятельности и принятия решений в орга-
низации. Полезно в данном контексте донести архитектуру и ее выгоды до максимально
большого количества людей, которых это касается. Это можно сделать:
 расклеивая постеры с моделями архитектуры во всей организации;
 обеспечивая применение архитектуры всеми структурными подразделениями при
определении объемов и принятии решений;
 обеспечивая запуск всех проектов с архитектуры как со стартовой позиции.
Шаг 6. Применение архитектуры
Любая организация, желающая использовать архитектуру процессов, должна наладить
необходимую дисциплину. Это означает, что все соответствующие проекты должны учиты-
вать архитектуру и выявлять, где они отклоняются от согласованных принципов.
Окончательное испытание любой архитектуры — решение, которое принимает руковод-
ство в случае намерения проекта отклониться от согласованных принципов архитектуры
процессов. В большинстве учебников и теорий утверждается, что архитектура должна быть
соблюдена принудительно. На практике этот подход нежизнеспособен: в большинстве ситу-
аций прямые выгоды бизнеса преобладают над долгосрочными архитектурными проблема-
ми. Однако, видимо, как только в качестве исключения позволяется отклониться от правил
архитектуры, люди ощущают себя полностью свободными и отклоняются от них все больше
и больше. Более того, как только лицо или проект получают свободу от строгой дисциплины,
другие тоже станут поступать, также с нарастающей скоростью. Это в конечном итоге при-
ведет к ситуации, при которой трудно или невозможно поддерживать архитектуру эффек-
тивно и результативно (рис. 14.10).

В DYA® (DYnamic Architecture. Вагтер и др., [77] — динамичная архитектура) пресле-

дуется весьма практичный подход к таким ситуациям: признается тот факт, что бывают слу-
чаи, когда срочные нужды бизнеса превалируют над архитектурными вопросами. Но вместо
борьбы с этим, руководству следует сосредоточиться на ограничение воздействия таких от-
клонений. Тем не менее, любое отклонение от согласованной архитектуры должно отвечать
следующим условиям:
  должны быть определены краткосрочные и длительные последствия отклонений
(например, дополнительные расходы на обслуживание);
 в предложении должно быть указано, каким образом решение будет соответствовать
согласованной архитектуре — либо оно будет постепенно выводиться из применения (что,
как правило, делается в случае разового проекта или проблемы), либо же двинется в сторону
согласованной архитектуры (как в случае новой версии приложения, которая решает требуе-
мые архитектурные вопросы);
 обоснование для отмены требований архитектуры должно быть утверждено на соот-
ветствующем уровне руководства, которое изначально утвердило архитектурное направле-
ние организации.
Данный подход можно сравнить с механизмом клапана скороварки (выпускание пара
защитным клапаном): когда давление становится слишком высоким, лучше контролируемо
снижать его (рис. 14.11), чем сопротивляться ему и получить в итоге взрыв (см. рис. 14.10).

Комитет по архитектуре бизнес-процессов

Полезный способ вживления архитектуры процессов в организацию — сформировать
комитет по архитектуре бизнес-процессов.
Данный комитет должен располагать полномочиями по поддержанию общего вида про-
цессов всей организации и архитектуры процессов. Комитет должен установить и поддержи-
вать связи между стратегическими целями организации и задачами процессов. Ему также
должно быть известно, в какой степени каждый процесс поддерживает определенную стра-
тегическую цель. (Вариант: проект работает по архитектуре процессов и вносится в храни-
лище данных архитектуры процессов).
При изменении стратегических целей организации комитет анализирует воздействие из-
менений, а затем направляет и изменяет бизнес-процессы, чтобы осуществлять новые стра-
тегические цели. Если это воздействует на архитектуру процессов, то изменения должны да-
вать обратную связь в архитектуру, чтобы она поддерживала и сохраняла адекватность.
Помните:
Увязка стратегических целей организации и поддерживающих процессов не происходит
сама по себе, а должна планироваться.
Комитет по архитектуре бизнес-процессов работает на постоянной основе, а не форми-
руется под конкретный проект.
Структура запуска проекта (СЗП). Чтобы в проекте применялась архитектура процес-
сов, организации следует выработать структуру запуска проекта (СЗП — PSA) на основе
DYA® [77]. СЗП обеспечивает резкий старт проекта, поскольку дает группе проекта необхо-
димые компоненты, не перегружая его чрезмерно полной архитектурой процессов, если в
этом нет нужды, т.е. СЗП — подмножество архитектуры процессов организации. В нее
включаются такие модели, как структурно-организационная схема, портфель продуктов, мо-
дели процессов и приложений, а также соответствующие методические руководства, отно-
сящиеся к ним. Преимущество СЗП в том, что она обеспечивает механизм, позволяющий не
тратить недели на сбор всей необходимой информации для более подробной архитектуры
проекта.
Шаг 7. Совершенствование и улучшение
Архитектуру процессов нельзя завершить — ее можно только улучшить.
Архитектура процессов всегда должна поддерживаться в актуальном состоянии, а для
работы с изменениями необходимо определить механизм управления ими. Это существенно,
поскольку любое изменение в архитектуре может повлиять на процессы, которые были раз-
работаны с использованием старых ее версий. Чтобы управление изменениями имело место,
необходимо четко определить, кто хозяин — владелец архитектуры.
 На этом шаге архитектуру можно уточнять и расширять. Во многих случаях полная ар-
хитектура в организации не определяется с первой попытки, и лучше действовать так: снача-
ла люди должны свыкнуться с широкими архитектурными вопросами и концепциями и по-
лучить быстрые выигрыши. После этого архитектуру можно расширять следующим обра-
зом:
 в ширину — включать больше элементов (например, вопросы ИТ);
 в глубину — включать больше подробностей (например, более детальные модели
процессов);
 по объему — включать больше процессов (например, создание моделей дополнитель-
ных процессов бизнес-подразделения).
И, наконец, не последний по важности момент: необходимо обеспечить, чтобы архитек-
туру использовали все больше и больше людей, например аудиторы, аналитики ИТ и бизне-
са.
Реальные выгоды архитектуры процессов со временем становятся очевидны: когда
наступают новые события и новые вызовы, меняется стратегия, или внедряется новая систе-
ма, архитектура процессов задает направление для оценки эффекта этих воздействий.
Шаг 7 должен обеспечить регулярную оценку архитектуры, чтобы она была полезна и
подходила для организации.
Реализация ценности. Здесь нужно описать механизм управления извлечением выгод и
преимуществ как части данного этапа. Подробности см. в главе 21, шаг 1, где это описано в
связи с реализацией ценности в рамках проекта.
Конкретные результаты архитектуры процессов
Этап архитектуры процессов дает ценный вклад в другие этапы общей схемы внедрения
(рис. 14.12). Приведем лишь несколько примеров:
 модели бизнес-процессов, создаваемые на этапах понимания и инноваций, использу-
ют архитектуру, созданную или уточненную на данном этапе;
 архитектура процессов дает общие методические указания по формированию объема
проекта и его организационной структуры на этапе стартовой площадки;
 по обратной связи данный этап подпитывает этап стратегии организации в плане це-
лесообразности и пригодности, а также способности организации реализовать стратегию в
рамках существующих процессов.

Риски этапа архитектуры процессов. Самые распространенные риски разработки ар-

хитектуры процессов приведены в табл. 14.1.
 Таблица 14.1. Риски этапа архитектуры процессов и стратегии их снижения

Риск Стратегия снижения риска

1. Смещение архитектуры в сто- Начните с целей и стратегии организации и при-

рону ИТ влеките руководство и бизнес-подразделение

4. Архитектура слишком детали- Начните с целей и стратегии организации и опус-

зирована кайтесь до получения обобщенных принципов

5. Архитектурой не пользуются Обеспечьте соответствие архитектуры требованиям

руководства и других заинтересованных сторон и
заинтересуйте их выигрышами

6. Архитектура всегда немного Подчеркивайте важность динамичной и сжатой, а

запаздывает не детально проработанной и трудно адаптируемой
архитектуры

7. Усилия в плане архитектуры Подойдите к архитектуре как к проекту с четким

приводят к многочисленным дискус- итоговым результатом и сроками
сиям без ощутимых результатов
Типовой образец этапа архитектуры процессов приведен в Приложении B.

Глава 15. Этап стартовой площадки. Назначение

Часто организации бывает очень трудно определить, где начинать проект BPM. Могут
быть известны проблемы и неэффективность работы конкретного подразделения предприя-
тия, однако весьма трудно решить, как и где начинать проект.
Кейс: «с чего начать?»
Руководитель дает указания менеджеру процессов: «найдите мне существенные усовер-
шенствования процессов, где можно добиться значительной экономии в организации». Ме-
неджер процессов был лишь недавно назначен на должность, и не знает, с чего начинать. Он
организовывает несколько групп проекта, чтобы процессно моделировать различными
участками бизнеса в их текущем состоянии. Перед этим не проводится общего анализа для
выявления вероятных областей экономии и нацеленных действий, поддержка проектов со
стороны высшего руководства незначительна или отсутствует вовсе, менеджеру процессов
не оказывается кураторской поддержки BPM. Проект, в основном, не оправдывает ожиданий
заинтересованных сторон, и большей частью уже через год свертывается.
Вывод. Без опытного специалиста во главе группы проекта и структурированного под-
хода группе будет трудно определить, откуда начинать двигаться упорядоченным образом,
который умножит потенциальные усилия.
Этап стартовой площадки (рис. 15.1) — это платформа, на которой масштабируются, ор-
ганизуются и запускаются проекты BPM (рис. 15.2).
 В случае применения подхода операционной инициативы на данном этапе выполняется
анализ на верхнем уровне процессов и деятельности организации, обеспечивающий ей воз-
можность определиться с логическим местом для начала исходной оценки усилий, требуе-
мых для проекта BPM вместе с возможным получаемым в результате выигрышем. В этом
может оказаться полезной и архитектура процессов.
При применении подхода, движимого стратегией, в большинстве случаев стартовая точ-
ка уже известна (хотя может потребовать уточнения).
Этот этап — просто способ начать проект, здесь выполняются действия, необходимые
для организации проекта ради его успеха, включая:
1. объем проекта,
2. выбор и структуру группы проекта,
3. ожидания заинтересованных сторон,
4. организационное оформление и распределение обязанностей,
5. определение первоначальных задач проекта и
6. использование стартовой архитектуры процессов для быстрого запуска проекта с ар-
хитектурной точки зрения.
Каждый последующий проект, запускаемый с данной стартовой площадки, получит воз-
можность перенимать опыт предыдущих проектов BPM, а не начинать с нуля, всякий раз
изобретая колесо (велосипед – С.К.). Чтобы организация продвигалась вперед, чрезвычайно
важно систематическое и структурированное внедрение в выбранный подход осмысленного
и освоенного опыта, накопленного ранее.
Результаты
Среди предполагаемых результатов этапа стартовой площадки перечислим:
1. Определение заинтересованных сторон, привлекаемых к проекту или связанных с
ним.
2. Привлечение и «заточенность» на проект заинтересованных сторон; документирован-
ные и согласованные ожидания.
3. Матрица выбора процесса.
4. Перечень выделенных бизнес-процессов и исходные метрики.
5. Перечень согласованных задач процессов.
6. Перечень в порядке приоритета процессов, выбранных для этапа понимания.
7. Первоначальная стратегия реализации.
8. Управление проектом:
o положение о проекте;
o описание объема проекта;
o первоначальная схема календарного плана проекта (этап понимания выполня-
ется детально);
o разработка и описание начальной стратегии распространения и доведения ин-
формации;
o исходный анализ рисков.
 9. Разработка исходного варианта экономического обоснования.
Осуществление
Чтобы успешно осуществить этап стартовой площадки, необходимо выполнить 9 серь-
езных шагов (рис. 15.3). Подход будет определяться выбором проекта и сценария его реали-
зации.

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

2. Первоначальные собеседования с заинтересованными сторонами

3. Общее знакомство с процессами

4. Определение и привлечение заинтересованных сторон

5. Совещания с участием руководства

5.1. Определение объема проекта

5.2. Определение задач процессов

5.3. Сверочный список достижения успеха

5.4. Перечень сквозных процессов

5.5. Выбор отдельных бизнес-процессов

5.6. Анализ бизнес-процессов

 5.7. Согласование конкретных результатов на выхо-
де этапа понимания
6. Разработка плана реализации

7. Разработка/утверждение бизнес-обоснования

8. Определение и формирование структуры группы проекта

9. Разработка исходного плана проекта

Рис. 15.3 Моя версия

Шаг 1. Обмен информацией

До начала этого этапа необходимо донести до персонала информацию о проекте, его за-
дачах, исходном или вероятном объеме и ориентировочных сроках. В некоторых организа-
циях проекты BPM отмечены «проклятьем» со времен Business process reengineering (BPR)3.
BPR в них равнозначно сокращению персонала, поэтому люди сначала затаятся. Эту про-
блему нужно снять с самого начала путем эффективного информирования и общения, объ-
ясняя людям, почему BPM — совсем другая «штука».
Распространение информации и сообщение ее людям должно продолжиться на всем эта-
пе и в проекте целиком, по мере уточнения его объемов и планов. Сообщаемая информация
должна включать постоянное обновление знаний о следующих действиях:
 как проект повлияет на персонал;
 какого поведения персонал может ожидать от руководства;
 как будут поступать с сотрудниками в результате изменений,
 как и насколько часто будет происходить обмен информацией, а также
 подробности о возможностях участия людей в проекте (всегда будьте открытыми и
честными).
Старайтесь предвосхищать вопросы и возражения и заранее быть готовым отвечать на
них. Анализируйте работу целевых групп и специально формулируйте сообщения для них,
выдерживая последовательность и согласованность.
Назначьте лицо, ответственное за общение, связи, распространение информации и
управление изменениями персонала; это лицо должно отчитываться за свою работу. Ответ-
ственный за связи должен быть привлечен к проекту на этом раннем этапе — необходимо
разработать план по связям и распространению информации (информационный регламент) и
начать его выполнение (см. главу 25, где рассматриваются предложения по содержанию ин-
формационного регламента и решению вопросов управления изменениями персонала).
Шаг 2. Первоначальные собеседования с заинтересованными сторонами
После обсуждений со спонсором проекта или бизнеса следует провести ряд собеседова-
ний с небольшим количеством представителей ключевых внутренних заинтересованных
сторон. Цель этих собеседований — получить общее представление о текущей ситуации в
бизнесе и состоянии бизнес-процессов и выяснить взгляды сторон на основные проблемы
операционной сферы и процессов. Эта процедура не должна затягиваться, а быть краткой и
строго деловой. При движимом стратегией подходе собеседования также должны касаться
информационных сообщений о том, как данный проект будет способствовать успешной реа-
лизации стратегии организации.
В результате собеседований:
 устанавливается контакт и связи с заинтересованными сторонами (как часть работы с
заинтересованными сторонами);
 формируется общее понимание проблем с точки зрения заинтересованных сторон;
 определяются быстрые выигрыши, которых страстно желают заинтересованные сто-
роны.
3
фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения мак-
симального эффекта производственно-хозяйственной и финансово-экономической деятельности, оформленное
соответствующими организационно-распорядительными и нормативными документами
 Этот шаг нельзя путать с шагом 4, где определяются все заинтересованные стороны и
лица проекта, что служит входными данными для стратегии управления отношениями с за-
интересованными сторонами, описанной в главе 24.
Шаг 3. Общее знакомство с процессами
Если первые участники группы проекта не знакомы с процессами данного подразделе-
ния, может оказаться чрезвычайно полезным провести пару дней, беседуя с людьми, выпол-
няющими процессы на своих местах, и отслеживая процессы в данном подразделении. Это
дает отличное общее представление о ведении бизнеса, а также возможность выявить разли-
чия и сходства в процессах.
Обсуждения с подразделением ИТ полезны в плане общего представления о взаимодей-
ствии бизнес-приложений и инфраструктуры (архитектуры ИТ) с бизнес-процессами, а так-
же с точки зрения их поддерживания приложениями и инфраструктурой.
Общее знакомство на этапе понимания не должно заменять действия, обеспечивающие
более глубокий анализ и понимание.
Шаг 4. Определение и привлечение заинтересованных сторон
Простой шаг — мозговой штурм с целью выяснить, кто заинтересован в проекте (как
внутри, так и вне организации). Внешние заинтересованные лица могут быть внутри органи-
зации, но вне данного подразделения, либо действительно вне пределов организации: клиен-
ты, партнеры и поставщики.
В конце данного шага определяются заинтересованные стороны, которые должны при-
вносить нечто свое в проект, и их необходимо держать в курсе проекта. Возможно, важных
заинтересованных лиц (клиентов или поставщиков) нужно не просто держать в курсе, но и
привлекать в проект и добиваться принятия ими проекта как своего. Усилия, вложенные в
перестройку процессов, разработку и внедрение новых процессов, будут потрачены впустую,
если клиенты и поставщики откажутся использовать их.
Привлечение заинтересованных сторон подробно рассматривается в главе 24.
Шаг 5. Практические совещания с участием руководства
Формат таких совещаний предусматривает трех- или четырехчасовые беседы по следу-
ющим вопросам:
 определение и согласование объема проекта;
 определение исходных целей проекта;
 согласование сверочного списка для определения успеха проекта;
 определение заинтересованных сторон и их объединение по категориям;
 разработка первоначального перечня моделей сквозных процессов;
 выбор отдельных бизнес-процессов;
 первоначальный анализ процессов, включая метрики высокого уровня (общие);
 согласование конкретных результатов этапа понимания.
Каждый из этих вопросов подробно рассматривается ниже.
Шаг 5.1. Определение объема проекта
Определение объема проекта — это, как правило, определение сферы проектного управ-
ления. Как указывалось выше, мы не намерены описывать методику проектного управления
в данной книге. Однако на один довлеющий вопрос ответить необходимо. Есть ли уверен-
ность, что исходно планируемый объем проекта обеспечит ожидаемые заинтересованными
сторонами результаты?
Во многих ситуациях бизнес-подразделение определит объем проекта уже, например, в
случае выбора проекта на основе подхода, движимого стратегией. К этому «исходному»
объему следует возвращаться, как минимум, на практических совещаниях с руководством, и
подтверждать его достаточность для всех заинтересованных сторон. Если операционные
подразделения намерены изменить объем проекта, выбранного методом, движимым страте-
гией, это необходимо довести до спонсора проекта и ведущих руководителей, поскольку та-
кое изменение может отразиться на стратегии организации. Важно также четко понимать,
что именно не включено в объем проекта.
Существенно, чтобы процессы, охваченные проектом и обсуждаемые на практических
совещаниях (т.е. понятые), действительно выполнялись по сквозному сценарию. Если это
означает пересечение границ между отделами, бизнес-подразделениями и даже заинтересо-
ванными сторонами, значит, нужно пересечь такие границы. Совещания на этапе понимания
нужно проводить ради «процессов», не беря во внимание организационные границы или
структуры. Например, если изучается конкретный отдел (представленный овалом на рис.
15.4), а процесс распространяется за его пределы, необходимо рассмотреть данный процесс в
других «прилегающих» отделах, покрывая, таким образом, и область «по ходу», и область
«против хода» процесса.

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

Организации нужно определиться с целью проекта. Что хочет бизнес от проекта BPM:
 простой мелкой или постепенной рационализации бизнес-процессов;
 перестройки существующих процессов, чтобы сделать их лучше (более эффективны-
ми, продуктивными, качественными);
 воспользоваться возможностью, чтобы полностью перестроить свою деятельность
путем инноваций процессов;
 пересмотреть цепочку создания ценности в отрасли и перестроить ее.
Эффект воздействия на организацию распространяется на верхние уровни по мере рас-
ширения «охвата» выбранным вариантом (см. сценарии BPM в главе 12).
После определения «широты охвата» проекта нужно (если это еще не было сделано) рас-
смотреть движущие силы необходимости инноваций. Для чего это нужно:
 организация должна измениться — внешние или внутренние факторы требуют изме-
нения процессов;
 организация хочет измениться — без изменения процессов она не сможет выжить в
существующей форме; необходимо резко поднять уровень обслуживания клиентов; нужно
существенно сократить затраты (снизить себестоимость) или повысить качество;
 организация может измениться — зрелость организации такова, что менеджеры те-
перь осознают наличие способности изменяться и, возможно, впервые знают, как постоянно
добиваться успеха изменений.
Шаг 5.2. Определение задач процессов
 Необходимо определить задачи процессов, чтобы правильно спланировать проект. Если
у организации нет достаточной информации для определения таких задач, невозможно пол-
ностью сформулировать и сформировать проект. В движимом стратегией проекте задачи вы-
сокого уровня, возможно, уже известны, поскольку были поставлены высшим руководством.
В проекте операционной инициативы задачи ставятся на практических совещаниях.
Задачи процессов нужно состыковать со стратегией и целями (целевыми показателями)
организации (это определяется на этапе стратегии организации). Эти задачи должны учиты-
вать:
 требования заинтересованных сторон;
 положение по сравнению с конкурентами.
Для определения задач процессов имеется несколько блоков входных данных:
 измеряемые показатели, используемые для оценки эффективности процессов на дан-
ный момент и планируемые для измерений в будущем;
 определение уровня, до которого планируется повысить эффективность, с учетом
имеющегося потенциала и наличия рисков;
 определение уровня планируемого усовершенствования — задача повышения эффек-
тивности на 80% кардинально отличается от повышения на 10%, и подход будет кардиналь-
но различаться. Возможно ли увеличение продолжительности процесса ради повышения ка-
чества? Все эти потребности необходимо четко сформулировать; они должны быть поняты и
согласованы всеми заинтересованными сторонами проекта;
 определение показателей функционирования процессов. Его нужно начинать с пред-
полагаемых показателей эффективности с точки зрения заинтересованных сторон, а затем
спускаться вниз до уровня показателей эффективности процессов;
 оценка управления функционированием и показателей эффективности работы персо-
нала, исполняющего процессы (подробнее см. главу 18);
 оценка показателей производительности, продуктивности и адаптируемости;
 количество измеряемых показателей должно быть умеренным — не более пяти;
 поиск возможностей определить «сверхплановые» показатели.
Также нужно видеть, какие изменения должны произойти в поведении персонала, вовле-
ченного в процессы: менеджеров, руководителей групп и рядовых работников.
Все задачи проекта должны быть «интеллектуальны» (SMART — конкретны, измеряе-
мы, достижимы, реалистичны и увязаны со сроками).
Шаг 5.3. Сверочный список достижения успеха
Это важный шаг в управлении ожиданиями заинтересованных сторон и сверки правиль-
ности объема проекта. С точки зрения проекта и бизнеса важно понимать, чего нужно до-
биться для успеха проекта. Хотя сверочный список обобщенных (высокого уровня) парамет-
ров успеха при подходе, движимом стратегией, определяется руководством высокого ранга,
мелкие детали определяются на этом шаге. В варианте операционной инициативы все крите-
рии успеха задаются в этот момент. Воспользуемся методом «бокала красного вина» и зада-
дим следующий вопрос: предположим, прошло шесть недель после завершения проекта, и,
сидя у камина с бокалом красного вина, вы размышляете о проекте. Вы считаете, что про-
ект был успешен. Почему?
Ответ на этот вопрос и должен дать сверочный список достижений — параметров успе-
ха.
Основания, по которым проект считается успешным, определяются во время практиче-
ских совещаний и должны включать, как конкретные результаты проекта, так и реальную
пользу для бизнеса. Проект не определяется только группой проекта — необходимо тесное
участие и глубокая вовлеченность бизнес-подразделений. Ведущий таких совещаний с руко-
водством должен также обеспечить увязку причин считать проект успешным с этапом стра-
тегии организации. В табл. 15.1 приведен пример лишь нескольких возможных ключевых
факторов успеха проекта BPM и распределение ответственности.
Таблица 15.1. Решающие факторы успеха проекта
Сверочный список параметров успеха проекта Ответственность

Проект Бизнес
1 Завершение проекта в срок и в рамках выделенно- ✓ ✓
го бюджета

2 По окончании этапа понимания достигнуто общее ✓

понимание действующих сквозных процессов
бизнес-подразделением и согласованы метрики –
измерение – С.К.??

3 Главные внешние заинтересованные стороны и ✓ ✓

руководство понимают корневые причины про-
блем процессов измерение – С.К.??

4 Персонал полон энтузиазма и видит путь вперед ✓

измерение – С.К.??

5 Определены быстрые выигрыши процессов, и они ✓

реализуются по ходу проекта измерение – С.К.??

Кейс: нужно следовать шагам методической схемы

Проводилось практическое совещание членов руководящего комитета проекта, и был
представлен объем проекта (согласованный со спонсором). Все члены комитета согласовали
объем проекта. Затем мы задали тестовый вопрос «бокала красного вина», чтобы выяснить
сверочный список успеха. При этом стало очевидно, что члены руководящего комитета не
согласны с объемом проекта, поскольку описанный сверочный список не соотносился с
предлагаемым объемом. Они согласились, что умом понимали, но сердцем не разделяли это-
го.
Вывод. Не выполнив шага сверочного списка успеха, проект начали бы в объеме, кото-
рый не отвечал требованиям руководящего комитета. Если бы проект завершился, он не удо-
влетворил бы ожиданий всех заинтересованных сторон, оказавшись пустой тратой времени и
денег.
Шаг 5.4. Перечень сквозных процессов
Модель сквозных (пронизывающих всю организацию) процессов дает общую картину
основных процессов. Если такая модель уже создана, нужно проанализировать ее, чтобы
подтвердить актуальность и справедливость для данного подразделения. Если такой модели
нет, ее необходимо разработать по методическим указаниям, предложенным для шага 2 гла-
вы 14.
В конкретном проекте разработанная модель сквозных процессов поможет выполнению
следующего шага — выбора отдельных бизнес-процессов, которые станут подпроцессами в
модели сквозных процессов. Лучший способ получить эту информацию — практические со-
вещания с руководством. Предлагаемые вопросы и подход подробнее описаны в Приложе-
нии D.
Шаг 5.5. Выбор отдельных бизнес-процессов
Перед началом проекта BPM нужно выбрать все релевантные отдельные бизнес - про-
цессы в анализируемом подразделении организации. Важно обеспечить охват сквозного
бизнес-процесса выбранными подпроцессами. Несмотря на наличие множества методик, мы
остановимся лишь на одной — матрице выбора процесса, потому что сами постоянно и
успешно используем ее.
Матрица выбора процесса (МВП — PSM) — это способ представить (обычно на одном
листе) все бизнес-процессы подразделения. Пример приведен на рис. 15.6. Более того, МВП
дает идеальную возможность понять и представить уровень сложности процессов, их коли-
чество и общие (высокого уровня) метрики на предприятии.
Вертикальная ось (основные процессы) исходит из сквозных процессов, выявленных на
шаге 5.4. Горизонтальная ось (сценарии) дает более подробный анализ процессов, указанных
на вертикальной оси. Эта картина меняется в зависимости от ситуации, которая может отоб-
ражаться продуктами организации, платежными методами, способами распределения, гео-
графическим охватом, бизнес-подразделениями и т.д. Важное замечание состоит в том, что
ячейки на пересечении вертикальной и горизонтальной осей представляют отдельный биз-
нес-процесс.

Если шаг процесса уникален, то процессный объект должен быть определен в данном
сценарии (Процесс 1, Продукт 1 и Основной процесс А на рис. 15.6). Если в сценарии не
предусмотрены шаги процесса, то процессный объект не должен определяться (например, у
Продукта 1 нет процесса, связанного с Основным процессом С). Если шаг процесса один и
тот же для нескольких сценариев, то процессный объект должен распределяться по ним (как
в Процессе 5, где у Продукта 1 и продукта 2 есть общий процесс, связанный с основным
Процессом B). Это типичный случай, когда:
 сценарии никак не влияют на уникальность шага процесса;
 процессы выполняются одними и теми же бизнес – подразделениями / функциональ-
ными группами;
 процессы поддерживаются теми же самыми ИТ-приложениями.
И снова наилучший способ получить эту информацию — провести практическое сове-
щание руководства с участием соответствующих менеджеров процессов и руководителей
групп.
Матрица выбора процессов — исключительно удобная стартовая точка проекта; она мо-
жет и будет модифицироваться по ходу проекта в силу углубления понимания или меняю-
щихся обстоятельств.
Шаг 5.6. Анализ бизнес-процессов
Выбор процессов, охватываемых проектом, кажется достаточно простой процедурой,
однако это чрезвычайно важный момент, и часто трудно сделать правильный выбор с перво-
го раза. Большинство организаций выбирают процессы интуитивно, сообразуясь с пробле-
мами, которые, по-видимому, создает данный процесс, или на основе догадок о выигрыше,
который принесет перестройка процессов. Хотя часто для начала это разумная точка, важно
в процедуру отбора привнести анализ целей уже по той простой причине, что необходима
проверка правильности «шестого чувства» персонала и руководителей.
При заполнении матрицы важно собрать метрики соответствующих звеньев цепочки, со-
здающей ценности и процессов. Среди полезных метрик процессов/рынка/продуктов:
 количество сотрудников, участвующих в исполнении процесса;
 количество и цена транзакций;
 численные показатели качества (например, удовлетворенность клиентов, объем пере-
делок, количество жалоб и т.п.), что равносильно проблемным участкам процессов;
 метрики времени обработки, сроков прохождения и времени ожидания, что равно-
сильно нахождению «узких мест».
Это подскажет, где необходим более углубленный анализ. Например, если процессы 3 и
5 на рис. 15.6 отнимают 70% ресурсов процесса, то любое их усовершенствование серьезно
отразится на затратах бизнес-подразделения. С другой стороны, если процесс 2 отнимает
лишь 4% ресурсов, то усовершенствования процесса в этом месте может не дать существен-
ного вклада в выигрыш по затратам для данного подразделения. Собранные метрики должны
вноситься в таблицу выбора процессов, которая становится мощным средством наложения
для руководства и проекта.
Если проект инициирован движимым стратегией подходом, то процессы, охватываемые
проектом, возможно, уже определены, но эта информация все равно будет полезна.
Матрица PSM, однако, не является единственным орудием ранжирования процессов по
приоритету, особенно в проектах операционной инициативы, поэтому качество и объем пе-
ределок также дают ключевую входную информацию.
Другая матрица, дающая интересную перспективу анализу бизнес-процессов — это мат-
рица ценности процесса Кина [38], приведенная в табл. 15.2.

Такой способ чрезвычайно полезен при определении бизнес-процессов, в которые стоит

вкладывать средства, но эту матрицу не всегда легко заполнить — процессы часто трудно
разбить на категории. Определения, используемые Кином, таковы:
 процессы - активы — любой процесс, который дает больше денежных средств пред-
приятию, чем затраты на него, является активом. Однако нужно правильно посчитать затра-
ты; разумеется, нельзя использовать традиционное бухгалтерское определение;
 процессы - пассивы — противоположность актива;
 процессы - «лицо» — идентифицируют «лицо» организации для себя самой, своих
клиентов и заинтересованных сторон. Это свойства, выделяющие компанию из ряда ее кон-
курентов. Например, деловая репутация сети ресторанов «Макдоналдс» основана на скоро-
сти и одинаковом обслуживании в любом ресторане, страховая компания AAMI известна
своим персонализированным доброжелательным подходом. Подобные восприятия рынком
должны обеспечиваться данными процессами. Такие процессы определяют «двуликую» ор-
ганизацию. Формирующие «лицо» организации процессы составляют часть «ключевых»
процессов, упомянутых ранее на рис. 14.7;
 приоритетные процессы — в значительной мере обеспечивают результативность
идентифицирующих «лицо» процессов. Клиентам такие процессы, как правило, не видны, но
если они не исполняются, это сразу же сказывается и становится заметно заинтересованным
сторонам. В примере с «Макдоналдс» в такие процессы включены участки, являющиеся ча-
стью цепочки поставок сырых продуктов для приготовления готовых блюд;
 фоновые процессы — обеспечивают каждодневную работу и функционирование
внутри организации, включая администрирование, управление персоналом и документацией.
Иногда эти процессы весьма заметны, и поэтому привлекают внимание руководства. Ставить
вложения в них впереди процессов идентификации и приоритетных процессов было бы
ошибкой. Многие организации выбирают для проектов BPM именно эти процессы, потому
что здесь можно получить быстрый выигрыш. Это опять же может быть ошибкой, если не
удается добиться наложения преимуществ и выигрыша по расходам, но если даже такие
преимущества совмещаются, больший выигрыш должен получиться, если сначала порабо-
тать над процессами-активами;
 вынужденные процессы — «навязаны» организации извне, например законодатель-
ством и нормативно-правовыми актами. У организации нет иного выбора, кроме их выпол-
нения. Обычно это процессы-пассивы, не дающие прямого вклада в создание ценности в ор-
ганизации.
 Другие процессы, которые могут существовать, но не отображены в матрице, можно
назвать привычными, поскольку сотрудники говорят о них «мы всегда так делаем». Если та-
кие процессы обнаруживаются, поставьте сотрудникам задачу оценить их реальную цен-
ность и необходимость, а затем либо включите их в список процессов, либо уничтожьте.
Хотя исходная матрица ценности процессов может быть сформирована в ходе проекта
BPM, это не должно быть разовым мероприятием. Такую матрицу следует включить в архи-
тектуру процессов и уточнять в ходе последующих проектов и повседневной деятельности.
Процессы со временем могут переходить из одной категории в другую. Обычно это вызыва-
ется бизнес - средой, решениями руководства, поведением персонала и организации в целом,
но может быть вызвано и непреднамеренным пренебрежением каким-либо процессом.
Кейс: над нужным ли процессом работаем?
Матрица ценности для организации на начальной фазе проекта показала, что два бизнес-
процесса представляли 52% людей, исполняющих процесс. Один процесс (32%) был класси-
фицирован как приоритетный/процесс-актив, а другой (20%) — как приоритетный/процесс-
пассив. Из всех вовлеченных в процесс людей 20% участвовали в обработке транзакции, ко-
торая имела отрицательную ценность для организации! По окончании анализа было выска-
зано соображение передать этот процесс на подряд (аутсорсинг).
Вывод. Заполнение матрицы ценности процессов — очень полезная методика, потому
что она помогает руководству понять и ранжировать процессы организации, позволяя при-
нимать более информированные решения.
Собрав информацию в матрице выбора процессов, матрице ценности процессов, соот-
ветствующие метрики и задачи процессов, нужно объединить все это для исключения, выбо-
ра и определения порядка, в котором процессы будут отрабатываться на этапе понимания.
Выполняя этот анализ, организация должна нацеливаться на создание ценности: ведь
получение преимуществ, пользы, выигрыша и выгод от реструктурирования процессов не-
обязательно создает ценность: «выигрыш — управленческое понятие. Ценность — экономи-
ческое понятие»[38].
Есть организации, которые получали значительную пользу и выигрыш от реструктури-
рования процессов, но при этом их прибыль падала. Усовершенствования процессов не все-
гда превращаются в прибыль. Например, перестроенный процесс может быть более эффек-
тивен, но не приносит выигрыша клиентам или не вносит вклад в ценность/прибыль пред-
приятия.
Процессы, выбранные для проекта перестройки BPM, должны добавлять ценность для
предприятия.
Шаг 5.7. Согласование конкретных результатов на выходе этапа понимания
Опять же речь идет об ожиданиях заинтересованных сторон. Гораздо лучше еще до
начала этого этапа довести до соответствующих сторон планируемые конкретные результа-
ты (и таким образом сформировать ожидания), чем завершить этап, но не оправдать ожида-
ний этих сторон. Если группа проекта не сформулирует ожидаемые результаты, заинтересо-
ванные стороны проекта сформируют свои собственные, а они редко совпадают.
Конкретные результаты этапа понимания включают:
1. Перечень моделей сквозных процессов.
2. Перечень сквозных подпроцессов.
3. Модели действующих процессов с детализацией, достаточной для выполнения этапа
инноваций.
4. Соответствующие метрики, дающие возможность задать точку отсчета для будущих
сравнительных измерений процессов.
5. Перечень основных проблем процессов, определенных бизнес-подразделениями.
6. Определение приоритетов для инноваций.
7. Выявление возможностей быстрых выигрышей.
8. Проверка и передача на реализацию возможностей быстрых выигрышей, если это це-
лесообразно на данном этапе.
9. Отчет по этапу.
Шаг 6. Разработка плана реализации
Важность собственно реализации невозможно переоценить. Распространен вопрос: «ка-
ким будет выигрыш проекта, если потратить больше денег и времени на реализацию?». От-
вет прост, но иногда трудно посчитать выигрыш сразу же. Четкая реализация обеспечит оп-
тимальность предложенного решения для организации, использование этого решения
наилучшим образом и в возможно кратчайшие сроки. Если реализация не проходит гладко,
может возникнуть одна или несколько следующих ситуаций:
 выбранное решение не оптимально для организации — это может быть вызвано не-
верным, неполным или несогласованным сбором требований, но все же большей частью вы-
зывается недостаточно плотным участием заинтересованных сторон и пользователей про-
цесса;
 организация использует решение не лучшим образом, поскольку пользователи недо-
статочно проинформированы, не обучены и не мотивированы;
 решение невозможно реализовать сразу же; необходимы изменения, что затягивает
сроки получения реальных преимуществ, и они не столь велики, как должны были быть.
Для традиционного подхода к реализации характерны скромные усилия и вложения в
начальный момент. К моменту внедрения решения приходится вносить изменения в послед-
нюю минуту, что ведет к существенным непредвиденным дополнительным вложениям и бо-
лее низким устойчивым результатам (рис. 15.7).

Если начать подготовку реализации на этапе стартовой площадки проекта, это поначалу
приведет к увеличению вложений, однако реализованное решение будет готово запуститься
с одного оборота, что быстрее даст лучшие устойчивые результаты (рис. 15.8 — Regatta®
фирмы Sogeti Nederland).
 Если сравнить два подхода, ясно видно, что, несмотря на аргумент увеличения вложений
на ранней стадии, преимущества такого подхода существенно выше по сравнению с тради-
ционным подходом (рис. 15.9 — Regatta® фирмы Sogeti Nederland).

В презентации «Привязка ИТ к эффективности предприятия: важна реализация», сде-

ланной Джорджем Лори из Forrester Research 21 мая 2003 года в Амстельвине, Голландия, на
церемонии представления книги Regatta® фирмой Sogeti Nederland говорилось: «Неважно,
сколько вы тратите на ИТ, важно — какие технологии вы покупаете, но самое важное — как
вы их внедряете». Этот вывод следует из осознания, что все больше и больше организаций
покупает и внедряет стандартные готовые пакеты, так что конкурентное преимущество про-
истекает не из самого инструментария, а из того, как он сконфигурирован и реализован в ор-
ганизации.
На этапе реализации рассматриваются различные варианты, которые следует изучить на
данном шаге, цель которого — обдумывание вариантов внедрения и выбор наиболее подхо-
дящего для проекта. Это задает направление для других этапов и шагов общей методической
схемы по мере продвижения проекта.
Кейс: преждевременное внедрение
Мы участвовали в проекте, где руководитель организации настаивал на его реализации к
строго определенной дате, хотя менеджер проекта, директор ИТ и директор операций друж-
но настаивали, что эта дата должна быть отсрочена на три месяца и что реализация в такие
сроки вызовет неразбериху в операционных областях бизнеса организации.
Внедрение проходило в навязанные сроки и действительно вызвало операционный хаос,
но мы впоследствии узнали, что руководитель организации получил существенную премию
за реализацию проекта «в срок»!
Вывод. Анализ заинтересованных сторон и понимание факторов, которые движут ими,
очень важны для успешного итога проекта.
Шаг 7. Разработка/утверждение бизнес-обоснования
Следует использовать стандартную типовую форму бизнес-обоснования, принятую в ор-
ганизации. Помимо обычного содержания обоснования BPM (которое подробно описано в
Приложении C), данное обоснование должно также включать:
 анализ приращения экономической ценности (EVA);
 внутреннюю подготовку предложений;
 документирование всех операционных затрат, не поддающихся количественному из-
мерению, выгоды и приращений экономической ценности, а также анализ рисков каждого из
них;
 рассмотрение «за» и «против» различных вариантов;
  использование критериев оценки сценариев и эффективности.
Группе проекта ни в коем случае не следует отстаивать сделанные рекомендации, а толь-
ко давать их и объяснять возможные варианты объективно и непредвзято [5].
В разработку обоснования входит и определение лица (лиц), которое будет отвечать за
процесс (процессы) после перехода проекта из «проектного» в рабочее состояние. Это нужно
для обеспечения участия данных лиц в проекте и принятии решений по проекту, чтобы у них
был некий уровень принадлежности к результатам проекта и ответственности за них.
Следует иметь в виду, что это лишь исходное обоснование, которое может обосновать
либо весь проект BPM, либо дальнейшее финансирование разработки подробного обоснова-
ния полного проекта. Бизнес-обоснование необходимо обновить или доработать на этапе ин-
новаций, чтобы оправдать продолжение проекта BPM (см. шаг 13 в главе 17).
Шаг 8. Определение и формирование структуры группы проекта
После принятия решения о последовательности изучения процессов на этапе понимания
(снова! как это???, это же этап стартовой площадки – С.К.) исходная группа проекта и биз-
нес-подразделения могут приступать к формированию структуры проекта BPM и группы
проекта. Структура проекта BPM может несколько отличаться от типичного проекта ИТ или
бизнес-проекта. Структура на рис. 15.10 предполагает, что одновременно с реализацией про-
екта BPM внедряется интегрированная система управления документами. Функциональные
обязанности рассматриваются более подробно в Приложении С.

Эта типовая структура проекта предназначена для широкомасштабной программы или

проекта внедрения BPM. Ее нужно адаптировать к конкретным требованиям организации и
проекта. Группа проекта редко начинает проект в таком составе на этапе стартовой площад-
ки. Однако необходимо определить и спланировать будущую структуру группы проекта. Ко-
личество и состав направлений работы, показанные на рис. 15.10, будут зависеть от проекта
и используемых элементов автоматизации. Мы представили только одно направление для
элемента управления документами; очевидно, что будут и другие для реализации модуля —
машины процессов (потока работ — workflow) и бизнес-правил. Данная структура, однако,
оказалась особенно эффективной, так что ее излишняя модификация может привести к сни-
жению результативности.
Руководящий комитет, директор и менеджер проекта. Функции и обязанности руко-
водящего комитета, директора и менеджера проекта, а также руководителей групп близки к
обычным функциональным обязанностям этих лиц в любом проекте, подробно рассмотрены
в Приложении С (стр. 241-243).
Здесь же мы остановимся на роли менеджера проекта, а затем на остальных ролях. Мы
настоятельно рекомендуем две ведущие должности в структуре проекта:
1. в бизнес-подразделении должен быть свой менеджер проекта, отвечающий за весь
проект. В конце концов, это проект для бизнеса, а не проект ИТ. Данная должность имеет
решающий вес, чтобы обеспечить выполнение требований бизнеса и отношение к ним как к
первостепенным. Части проекта, относящиеся к ИТ, поставщику и другим составляющим,
подотчетны этому бизнес-менеджеру проекта. В идеале, такой менеджер должен быть опыт-
ным проектным управляющим со знанием специфики BPM. Если он не владеет BPM (а вла-
дение означает реализацию нескольких проектов), требуется опытный консультант BPM вы-
сокого ранга.
Привлечение такого опытного консультанта BPM настоятельно рекомендуется не только
для курирования и обучения бизнес-менеджера проекта, если тому не хватает знаний BPM,
но и для оказания помощи:
 в объективном «разруливании» ситуаций в ходе проекта, когда необходимы компро-
миссные решения по проекту или процессам, что неизбежно случается. Такие решения могут
иметь весьма серьезные последствия, и специалист-эксперт сможет справиться с рисками,
чтобы предотвратить превращение проекта BPM в дорогостоящее мероприятие по совер-
шенствованию бизнес-процессов со скромной отдачей;
 в сохранении фокуса и направленности проекта и его самофинансировании и созда-
нии реальной ценности для бизнеса;
 в нахождении дополнительных возможностей бизнеса, которые могут реализовывать-
ся BPM;
 в обеспечение правильного внесения в план проекта необходимых элементов управ-
ления изменениями персонала, что означает управление этими элементами как важнейшей
частью проекта;
 в извлечении пользы из работы с заинтересованными сторонами и обеспечении про-
фессионализма, который нужен, чтобы заинтересованные стороны были постоянно вовлече-
ны в проект и ориентированы на успешное внедрение BPM.
Хотя некоторые из перечисленных функций могут показаться обязанностями директора
или менеджера проекта, мы убедились, что независимый консультант часто способен выска-
зывать мнения и суждения, которые политически проблематичны для лиц внутри организа-
ции.
Группа проектных решений должна решать как можно больше вопросов, чтобы не пе-
редавать их в руководящий комитет. В нее должны входить главы всех подгрупп пользова-
телей, а возглавлять ее должен главный руководитель процессов или назначенный спонсор
процесса. Обязанности каждой из этих должностей перечислены в Приложении С.
Структура более мелких проектов BPM может потребовать объединения некоторых
должностей, но лидерство чрезвычайно важно для любого проекта, особенно для проекта
BPM, поэтому в данной области не должно быть никаких отступлений. Более подробно ли-
дерство и ведущая роль рассмотрены в главе 26.
Комитет выполняет обычную роль подобного комитета в проекте. В него, как правило,
входит спонсор проекта, менеджер и бизнес-менеджер проекта, владелец бизнес-процесса,
руководитель ИТ или сотрудник ИТ высокого ранга (если в проекте есть значительная ИТ-
составляющая), а также один-два человека, представляющие организационные аспекты, что-
бы обеспечить достижение синергии по всей организации.
Комитет по архитектуре бизнес-процессов рассматривался на этапе архитектуры про-
цессов.
Подгруппы процессов. Группа разбивается на различные процессные подгруппы (часто
их называют направлениями работ). Разумеется, количество подгрупп зависит от размера
проекта и его сложности. В крупном проекте с автоматизацией можно предположить нали-
чие небольшой подгруппы специалистов по процессам (возможно из Центра совершенство-
вания бизнес-процессов), подгруппы ИТ, занимающейся вопросами интерфейса и другими
работами по системной разработке, а также подгруппы, владеющей вопросами управления
документами, которая оказывает консультационную помощь всем подгруппам, особенно
выполняющим анализ и инновации процессов. В зависимости от размера проекта в каждую
подгруппу входят следующие специалисты:
 глава подгруппы;
 руководитель пользователей;
 представитель подгруппы пользователей;
 эксперт по процессам.
Кейс: необходимость в знающем бизнес-менеджере проекта с опытом BPM
Организация настаивала на назначении менеджера проекта, в чьи обязанности входило
бы преодоление разрыва между бизнес-подразделением и ИТ. Но этот менеджер был подот-
четен подразделению ИТ и мало понимал во внедрении BPM. Когда проект стал отставать от
графика реализации, нас попросили провести анализ состояния проекта. Результатом этого
стало курирование и обучение менеджера проекта, а один из наших менеджеров высшего
звена участвовал в работе комитета, делая постоянные замечания и рекомендации непосред-
ственно бизнес-спонсору проекта.
Если бы организация сразу уделила больше времени подбору подходящего бизнес-
менеджера проекта, задержек и превышения бюджета проекта можно было бы избежать.
Вывод. Выбор опытного бизнес-менеджера для проекта BPM – это одно из наиболее
важных решений, связанных с проектом. Потратьте необходимое время и деньги, чтобы
назначить правильного человека на эту должность, и он отплатит вам сторицей на протяже-
нии всего срока жизни проекта.
Каждая из этих ролей кратко описана в данной главе, а более подробно — в Приложении
С (стр. 241-243).
1. Глава подгруппы. Возглавляет подгруппу и ведет направление работ, обеспечивая ор-
ганизацию практических совещаний, разработку плана проекта (вместе с менеджером проек-
та), соблюдение плана — графика работ, выполнение бюджета и т.п.
2. Руководитель пользователей. Это лицо — бизнес-ресурс, назначаемый бизнес-
руководством. Оно наделено полномочиями принимать решения от имени бизнес-
подразделений.
3. Представитель пользователей в подгруппе. Технические специалисты или эксперты в
областях знаний из бизнес-подразделений. Их выбирает глава пользователей.
4. Эксперт по процессам. Эта группа формируется в Центре совершенствования бизнес-
процессов, обеспечивая квалифицированную помощь и профессионализм:
o при проектировании, разработке и реструктурировании (перестройке) процес-
сов;
o в инструментарии разработки процессов, используемом в проекте;
o в раздельном учете затрат по типам деятельности;
o в имитационном моделировании процессов;
o в планировании ресурсов;
o во взаимодействии процессов.
Если в организации нет Центра совершенствования бизнес-процессов или профессиона-
лов внутри, то опыт и знания в этой области может предоставить специализированная кон-
салтинговая организация BPM.
Подгруппа разработки ИТ
Члены этой подгруппы в большинстве своем являются специалистами во взаимодей-
ствии систем. Они обладают опытом и знаниями и работают с другими подгруппами, чтобы
интерфейсы процессов с различными системами работали успешно.
Подгруппа управления документами
В данную подгруппу входят специалисты по управлению документами и бизнес-
персонал, который разбирается в документообороте и использовании документов в своих
бизнес-областях. Эта подгруппа вносит вклад в работу других подгрупп, обеспечивая глад-
кую интеграцию документов и изображений в каждый процесс.
 Шаг 9. Разработка исходного плана проекта
Исходный план проекта подробно охватывает этап понимания с включением шагов эта-
па инноваций, но на данной фазе без увязки по срокам этого этапа.
По нашему опыту, должно быть проведено не более четырех практические совещаний
«понимания» по 3–4 часа в неделю, а время между ними следует посвятить:
 отработке моделей,
 рассмотрению и анализу результатов исследований в бизнес-подразделениях (вклю-
чая анализ корневых причин),
 сбору и завершению анализа метрик.
Более подробно это рассматривается в главе 16.
Количество смоделированных на каждом практическом совещании процессов зависит от
объема и сложности процессов.
Нельзя забывать о включении в план проекта действий на случай непредвиденных об-
стоятельств и следует иметь в виду, что составление отчета по окончании этого этапа всегда
отнимает больше времени, чем вы думаете, так что отведите на отчет достаточно времени —
тут нельзя торопиться. На самом деле отчет заполняется по ходу проекта. В Приложении С
приведены типовые формы отчета и плана проекта (стр. 245-246).
Реализация ценности. На данном этапе должны быть определены и спланированы по-
тенциальные выигрыши. Обратитесь к шагу 2 главы 21, где это описано в контексте реали-
зации ценности в проекте.
Конкретные итоги этапа стартовой площадки. Информация, выработанная на этапе
стартовой площадки, будет использована на входе различных этапов, как показано на рис.
15.11.

Очевидно, что она будет применяться на входе этапа понимания, где разрабатывается
план проекта, процессы ранжируются посредством матрицы выбора процессов, решаются
вопросы исходных метрик и бизнес - обоснования, а также определяется документация про-
екта. Бóльшая часть этой информации, например, задачи процессов, также перетечет на этап
инноваций.
Риски этапа стартовой площадки. На данном этапе формируется платформа, с которой
будут запускаться проекты. Как и в любом проекте, если платформа неправильно установле-
на, будет трудно вернуть проект на верный путь. Необходимо учесть несколько рисков и ре-
ализовать стратегию борьбы с ними, чтобы устранить (или хотя бы снизить) их. Некоторые
из рисков указаны в табл. 15.3.
Таблица 15.3. Риски этапа стартовой площадки и стратегии их снижения
Риск Стратегия снижения
1. не определены и/или не  определить все заинтересованные стороны проекта
вовлечены в проект заинтере-  привлечь все заинтересованные стороны в проект
сованные стороны

2. Менеджер проекта не  заменить менеджера проекта лицом, имеющим опыт BPM

имеет опыта в проектах и  обеспечить для менеджера проекта кураторство и настав-
внедрении BPM ничество опытного менеджера проектов BPM
 продолжить проект с неопытным менеджером проекта, но
с учетом возросшего риска для проекта

3. Нечетко определен  уточнить объем проекта со спонсором проекта

объем проекта, и/или он не  не продолжать проект, пока четко не сформулирован, не
ясен и не согласован согласован и не утвержден его объем

4. Проект недостаточно  обратиться к спонсору проекта за дальнейшим финанси-

финансируется рованием
 остановить проект, пока не возобновится финансирование

Глава 16. Этап понимания. Назначение

Цель этапа понимания (рис. 16.1) — достижение членами группы проекта и бизнес-
подразделения достаточного понимания действующих бизнес-процессов, что позволит при-
ступить к этапу инноваций. Это предусматривает сбор соответствующих метрик, который
позволит лучше понять, определить приоритеты инноваций/перестройки и установить срав-
нительные реперные точки отсчета для текущего состояния. Такие точки дают возможность
проводить сравнение с будущими сценариями инноваций процессов, которые будут опреде-
лены на следующем этапе – инноваций - и позволят завершить шаги имитационного модели-
рования и раздельного учета затрат по типам деятельности.
Группа проекта должна также понимать бизнес-цель данного этапа. Созданные модели
процессов могут применяться не только как входные данные для этапа инноваций, но и как
модели для обучения и документирования на этапах инноваций и внедрения.
Этап понимания должен также подтвердить правильность видения реально действую-
щих процессов внутри организации и определить приоритеты совершенствований в рамках
проекта. Это поможет выявить требуемые изменения в процессах, если они вообще необхо-
димы.
Решающим моментом здесь является стремление группы проекта и бизнеса понять про-
цессы, а не только задокументировать их вплоть до мельчайших подробностей. Если процесс
четко понят и задокументирован, можно нажать на тормоз: этого достаточно. Если с бизне-
сом достигнуто согласие о возможности применения моделей процессов для документиро-
вания и обучения, нужно оговорить уровень детализации в моделях процессов.
Результаты. Бизнес может рассчитывать на несколько результатов и выходных данных
этого этапа, в том числе:
1. модели действующих сегодня процессов.
2. Адекватные метрики, достаточные для установления точек отсчета при измерении
усовершенствований процессов в будущем, расстановки приоритетов и выбора процессов
для этапа инноваций.
3. Измерение и документальное фиксирование текущих или фактических уровней эф-
фективности.
4. Документирование того, что работает хорошо (для переноса на этап инноваций) и
может работать лучше.
5. Выявление быстрых выигрышей, которые могут быть реализованы в течение трех-
шести месяцев.
6. Отчет этапа.
Осуществление. Прежде всего, посвятим несколько секунд рассмотрению глубины и
подхода этого этапа. Как указывалось выше, моделирование на этапе понимания следует вы-
полнять лишь до момента, когда все участники (группа проекта и бизнес-подразделения)
пришли к общему пониманию того, что происходит с действующими бизнес-процессами, и
когда имеется достаточно данных и метрик, чтобы начать этап инноваций. В ходе данного
этапа следует иметь в виду несколько обстоятельств:
 «понимайте», что фактически происходит;
 убедитесь, что документированное отражает реальную, а не воображаемую (как
должно было бы быть) ситуацию;
 обеспечьте, чтобы моделируемые/понимаемые процессы (или процесс) были действи-
тельно сквозными и непрерывными (более подробно это рассматривается на шаге 3 данного
этапа);
 убедитесь, что сотрудники на практических совещаниях не тушуются и не считают,
что их оценивают: в противном случае участники, возможно, говорят то, что, по их мнению,
от них хотят услышать, и не делятся своими знаниями или могут давать неточную информа-
цию;
 установите пределы времени, которое можно посвятить пониманию или моделирова-
нию конкретного процесса, и обеспечьте соблюдение этих сроков — другими словами,
определите отчетные даты и установите сроки выполнения определенных работ. Если не по-
ставить даты отчетности, вы рискуете потратить слишком много времени на практические
совещания, и напрасно потеряете ценное время специалистов по отдельным предметным об-
ластям бизнеса, слишком углубляясь в детали. С одной стороны, совещания могут быть за-
нимательными и рискуют стать самоцелью, что, конечно, не является их задачей. С другой
стороны, участникам может стать скучно, и они могут прекратить посещать их;
 воспользуйтесь принципом Парето (правило 80/20), чтобы решить, когда вы прекра-
щаете получать желаемую отдачу;
 все время спрашивайте себя, получено ли достаточно информации, и можно ли на
этом остановиться.
Кейс: чрезвычайно важно участие в практических совещаниях нужных людей
Нам приходилось присутствовать на практических совещаниях, где участвовали бизнес-
специалисты из различных областей организации и фактически «обговаривали» процесс на
наших глазах, по мере его моделирования, пока мы догадались, что происходит. После этого
мы обоюдно понимали, к чему идет дело, и просили участников совещания по одному объ-
яснять нам процесс, а затем остальные поправляли его в своей части.
Вывод. Всегда нужно, чтобы на совещании были люди, которые до тонкостей знают
процесс, и если они из разных подразделений или областей, где процессы могут быть раз-
ными, потребуйте моделировать процессы по очереди, пока не наступит уверенность в полу-
чении общей картины единого процесса.
Ниже приводится несколько аргументов «за» и «против» моделирования на этапе пони-
мания.
Аргументы в пользу моделирования процессов:
1. Достижение общего понимания и общего языка проблемы.
 2. Выявление изъянов сложившейся ситуации.
3. Поддержка одобрения «разморозки» проекта.
4. Возможность оценить завершенность инноваций процессов.
5. Созданные модели могут использоваться для документации процесса, если нет острой
необходимости изменения процессов.
6. Персонал привыкает к процессному мышлению и моделированию процессов.
7. Определение точки отсчета для взаимодействия процессов с организацией, ИТ и пер-
соналом.
Аргументы против моделирования процессов:
1. Сегодняшняя моделируемая ситуация устаревает, едва только спроектированы новые
процессы и внедрены перестроенные процессы.
2. Всегда существует опасность «узкофокусного» проектирования процессов, что нала-
гает ограничения на осмысление инноваций процессов.
3. Отнимает время, требует привлечения и напряжения ресурсов бизнес-подразделений
и стоит денег; в большинстве случаев, это будет сложная процедура, причем кривая получе-
ния знаний на первых порах будет достаточно крутой.
4. Существует опасность перегрузиться информацией и погрязнуть в деталях.
Шаги, выполняемые на этапе понимания, показаны на рис. 16.2.

Шаг 1. Обмен информацией. На данном этапе основные действия по распространению

информации связаны с предоставлением заинтересованным лицам и сотрудникам внутри ор-
ганизации сведений о проекте, его целях, способах и сроках привлечения персонала на этапе
понимания. Например, именно на этом этапе проект обретает расширенную видимость в ор-
ганизации, поскольку персонал начинает участвовать в практических совещаниях и задавать
вопросы относительно текущей работы в процессах и связанных с этим метриках. У некото-
рых это может вызвать озабоченность в связи с их будущим положением в организации. Ес-
ли такую озабоченность не рассеять сразу и полностью, будет трудно добиться поддержки
сотрудников.
Группе проекта нужно создать атмосферу, в которой люди ощущают себя свободными в
предоставлении информации, необходимой для проекта и практических совещаний. Сотруд-
ники не должны стесняться делиться реальными проблемами и вопросами, и не опасаться,
что на них возложат вину.
Шаг 2. Перепроверка объема проекта. Очень важно постоянно сверяться с объемом
проекта, и самый удобный момент для этого — до начала практических совещаний этапа по-
нимания.
Может оказаться полезным навестить некоторых заинтересованных партнеров (постав-
щиков, клиентов и каналы сбыта) и смоделировать их процессы, чтобы понять, как они сты-
куются с вашими процессами, и как ваши процессы смогут укрепить бизнес-процессы парт-
неров — заинтересованных сторон. Это даст следующие преимущества:
 будет способствовать получению организацией более ясного понимания сквозных
процессов, что поможет повысить результативность инноваций процессов;
  даст возможность высказать заинтересованным сторонам мнение о перестройке их
процессов (процесса) совместной работе по осознанию того, как этого добиться и полностью
интегрироваться с вашими процессами (процессом);
 даст возможность организации минимизировать дублирования и нестыковки, сокра-
тить и отладить обмены между процессами вашей организации и заинтересованных сторон.
Шаг 3. Совещания на этапе понимания. Спонсору проекта и бизнес-подразделениям
важно четко осознавать, для чего необходим этот этап. Нам редко приходилось сталкиваться
с каким-либо сопротивлением ему, но мы встречались с руководителями, которые считали,
что моделирование всех процессов займет лишь пару часов.
Если вы натолкнетесь на сопротивление, и нужно будет разъяснить, для чего необходим
этап понимания, вот несколько аргументов:
1. достижение общего понимания фактов, характеризующих действующие процессы, а
не того, что происходит, по мнению руководства.
2. Анализ возможности или даже необходимости усовершенствований. Некоторые про-
цессы, возможно, нуждаются в отладке (скромных изменениях); другим нужна полная пере-
стройка с использованием в целом того же подхода, но его более эффективное осуществле-
ние; иногда процессам могут потребоваться инновации с использованием абсолютно нового
подхода, а некоторые процессы вообще не требуют изменений.
3. Помощь в понимании взаимодействия процессов и их влияния на другие процессы,
например, перехода от одного подразделения к другому (передачи).
4. Понимание и документирование стыков с существующими унаследованными систе-
мами и приложениями, что существенно для этапа инноваций, особенно если предполагается
автоматизация процессов.
Среди побудительных мотивов моделирования процессов можно назвать:
 документирование,
 стоимость,
 имитационное моделирование,
 соответствие требованиям законодательства (например, Сарбанес-Оксли4, Базель
II5),
 программное обеспечение (выбор, оценка, конфигурация, разработка),
 помощь в перестройке организационной архитектуры,
 планирование людских ресурсов,
 управление проектами, знаниями, документами и взаимоотношениями [61].
Перед началом практических совещаний важно иметь четкое понимание того, для чего
моделируются процессы, чтобы обеспечить увязку завершенных моделей с поставленной
целью. Не стремитесь к совершенству, постарайтесь создать модели, которые достаточно
закончены, практичны и «пригодны для намеченной цели». Всегда помните о принципе Па-
рето (правило 80/20), поскольку «лучшее — враг хорошего». Совершенство на данном этапе
может оказаться чрезвычайно дорогим удовольствием, что может случиться с полномас-
штабным подходом по методике шести сигм.
Постоянно следует иметь в виду следующие вопросы:
1. Пригоден ли процесс для цели, которой он предназначен служить?
2. Удовлетворяет ли процесс бизнес-требованиям, под которые он выстроен?
3. Является ли процесс критически важным для результатов деятельности или целей
бизнеса?
Устраивая совещания на этапе понимания, нужно помнить три момента, обеспечиваю-
щих их успешное проведение:
1. заблаговременно планируйте совещания на удобное для участников из бизнес-
подразделений время (шаг 3.1).

4
Этот закон был принят Конгрессом США после серии скандалов и разоблачений махинаций в руководстве
крупных фирм, в первую очередь — энергетического гиганта, компании Enron, и телекоммуникационной ком-
пании Wordlcom, которые с помощью бухгалтерских уловок раздували прибыль и поддерживали высокую цену
акций. Закон ужесточает учет и отчетность, но вызывает дополнительные, иногда значительные, затраты на
соблюдение требований закона — Прим. науч. ред.
5
Система Базель II - международные стандарты банковской деятельности, отличающиеся сложным подходом к
оценкам операционных и кредитных рисков — Прим. науч. ред.
 2. Добейтесь, чтобы внутренняя установка и умонастроения участников были подготов-
лены до начала совещания для формирования правильных ожиданий (шаг 3.2).
3. Проводите совещания организованно и управляемо (шаг 3.3).
Шаг 3.1. Заблаговременное планирование совещаний на удобное время
Практические совещания на этапе понимания могут оказаться весьма продолжительны-
ми, и потребовать отвлечения специалистов от исполнения их обычных обязанностей на
длительные периоды, отрывая их от нормальной повседневной работы.
Отвлечение ключевых сотрудников от работы на значительное время для участия в
практических совещаниях всегда представляет серьезную проблему. Членам группы нужно
проявить внимание и понимание этого и запланировать совещания так, чтобы они как можно
полнее отвечали нуждам бизнеса, одновременно укладываясь в установленные сроки выпол-
нения проекта. Чтобы добиться оптимальных для проекта и бизнеса результатов, важно при-
влечь к совещаниям именно лучших специалистов, а не тех, кто свободен на данный момент.
Вот почему так необходимо целеустремленное участие бизнеса.
График проведения совещаний должен быть согласован с руководством бизнес-
подразделений и спонсором проекта как можно раньше, с обеспечением помещениями и
оборудованием. Подготовка совещаний имеет важнейшее значение и должна предусматри-
вать:
 заблаговременное планирование задолго до проведения, чтобы обеспечить участие
ключевых специалистов;
 количество совещаний с учетом возможных непредвиденных обстоятельств, потому
что обычно работа занимает больше времени, чем планировалось;
 длительность совещаний (не более трех часов).
Шаг 3.2. Формирование умонастроений участников
Необходимо сформировать ожидания спонсора проекта и участников как можно раньше,
разумеется, задолго до их появления на первом совещании. Если вы не сформулируете ожи-
дания для участников, то они сформируют свои собственные, не всегда пригодные в данных
обстоятельствах.
Формат и задачи совещаний нужно обсудить и согласовать со спонсором проекта и/или
владельцем бизнеса, определить повестку и провести предварительную встречу с участника-
ми до совещаний. Председателем на этой встрече должен быть спонсор проекта (при содей-
ствии руководителя).
Спонсор проекта должен донести до участников важность проекта, их роль в нем и
необходимость участия в совещаниях. Руководитель совещаний должен описать общий
формат, роль участников, что от них ожидается, а также задачи совещаний под углом зрения
проекта.
Шаг 3.3. Организованное и контролируемое проведение совещаний. Кому нужно участ-
вовать?!
Мы бы советовали привлечь следующих лиц для работы на совещаниях:
 фактических исполнителей процессов, а не менеджеров, которые считают, что зна-
ют, как работают процессы;
 глав подгрупп, если они достаточно хорошо разбираются в процессе (процессах).
Спонсору проекта всегда полезно время от времени заглядывать на совещания, оставаясь
незаметным и больше слушая, чем участвуя в обсуждениях.
Повестка совещаний
В начале первого совещания нужно сделать презентацию, чтобы более подробно расска-
зать участникам о проекте и порядке проведения совещаний. Повестка, формат и предлагае-
мый набросок презентации подробно описаны в Приложении D (стр. 254 - 255); но несколько
замечаний хотелось бы сделать сейчас:
1. нет единственного правильного способа выполнить моделирование процессов: у каж-
дого свой предпочтительный метод. Нам нравится использовать инструмент моделирования
в лэптопе с показом картинки модели на настенном экране по ходу создания модели процес-
са. Нам видится, что такое применение инструмента моделирования процессов способствует
дискуссии, позволяя участникам видеть и понимать процесс во время его создания на их гла-
зах. Этот метод также позволяет участникам ближе познакомиться с инструментом модели-
рования; на самом деле, часто доходит до того, что специалисты по предметным областям
бизнеса хотят «захватить» инструментарий моделирования. Как только это начинает прояв-
ляться, знайте, что бизнес начал становиться «хозяином» процесса, так что вам удалось
увлечь бизнес-участников, а это, конечно, прекрасный результат. Методы моделирования
здесь обсуждаться не будут; на эту тему есть много книг, мы же остановимся лишь на шагах
этапа понимания.
2. Всегда соблюдайте запланированное время и сроки. Моделирование действующих
процессов может быть увлекательным занятием, но нужно придерживаться запланированно-
го графика и не допускать, чтобы специалисты заскучали.
3. Избегайте монополизации доминирования одного лица на совещаниях.
4. Как упоминалось выше, моделирование на этапе понимания нужно довести только до
той точки, когда достигнуто понимание происходящего, и имеется достаточно информации
для начала этапа инноваций. Что это означает конкретно? Какие детали нужно смоделиро-
вать? Разумеется, это зависит от конкретной организации и задач проекта. Самый простой
способ определить, когда закончить моделирование — постоянно задавать себе вопрос:
«Можем ли мы закончить моделирование сейчас?» Если ответ «да», остановитесь.
Кейс: сквозные процессы чрезвычайно важны
Мы работали в страховой фирме, изучая трудозатраты и практическую работу в финан-
совой сфере. Кто-то из сотрудников заметил, что один конкретный процесс мог бы «весьма
сильно улучшиться, если бы отдел подписки на полисы правильно делал свою работу». Мы
обнаружили, что около 50% трудозатрат финансовой сферы в этом процессе посвящалось
исправлению ошибок, сделанных отделом подписки, который и понятия не имел, какое вли-
яние оказывает на финансы. Совместное практическое совещание отдела финансов и под-
писки полисов смоделировало сквозной процесс, что позволило отделу подписки понять
ключевой характер основных шагов процесса. Исправив процесс, удалось добиться суще-
ственного снижения трудозатрат в финансовом отделе.
В данном случае «процесс» проведения совещания для достижения общего понимания и
осуществления был более важен, чем само моделирование. Моделирование стало просто ме-
тодом продемонстрировать влияние способа выполнения отдельных шагов процесса.
Вывод. Всегда моделируйте сквозные процессы вместе со всеми участниками совеща-
ний. Иногда «дорога» более важна, чем полученный результат (модель).
Не верьте всему, что вы слышите. Сомневайтесь в предоставленной информации, если
она неправдоподобна, чтобы выяснить реальную ситуацию. Людям, возможно, соблазни-
тельно сказать вам то, что, по их соображениям, вы хотите услышать, или руководство мо-
жет описать ситуацию, которую оно считает реально происходящей. Чрезвычайно полезный
способ понять реальную ситуацию — проверить смоделированные на совещаниях процессы
на рабочих местах «контрольным обходом».
Полезно зафиксировать идеи (возможности), выдвинутые во время совещаний, и занести
в журнал вопросов и перспектив. Такой журнал нужно вести в течение всего проекта — его
типовой образец приведен в Приложении D.
Шаг 4. Анализ метрик. Цель сбора метрик бизнес-процессов двойная:
1. Способствовать пониманию процессов и их влияния на организацию, а также сфор-
мулировать приоритеты для дальнейшего изучения.
2. Дать эталонную точку отсчета в целях сравнения с этапом инноваций проекта. Это
сильно поможет в завершении бизнес-обоснования и определения ожидаемой эффективно-
сти, снижения затрат и улучшения качества сервиса.
Для чего нужен анализ метрик? Вот некоторые аргументы в его пользу:
 содействие пониманию процессов в организации;
 предоставление аналитической картины организации;
 сопоставление затрат на процессы организации с бюджетом подразделений, чтобы
знать, что все главные процессы либо охвачены, либо намеренно исключены;
 помощь главам подгрупп выработать меры, реально решающие проблему, а не по-
верхностные решения;
 помощь в выстраивании приоритетов процессов для дальнейшего изучения на этапе
инноваций;
 предоставление базы для сравнения с любыми изменениями в будущем, обеспечивая
прогноз потенциальных выигрышей от вновь сформированной процессной среды, а также
измерения влияния реальных перемен;
  обеспечение входного материала для целеполагания работ по перестройке процессов
с выделением областей, где имеется потенциал для наибольшего воздействия;
 предоставление возможности сравнивать данные процессов (время выполнения зада-
ний, объемы и затраты) между различными организациями.
Перед началом практических совещаний на этапе понимания будут собраны и проанали-
зированы некоторые исходные метрики, что включает:
 сбор информации широкого плана по затратам, например бюджеты, структурно-
организационные схемы, фактические штаты сотрудников;
 сопоставление структурно-организационных схем и наличного персонала;
 реструктуризацию бюджета, если он спланирован для части организации, которая
крупнее анализируемой. В данной ситуации бюджет должен разбиваться — необходимо вы-
делять средства для конкретной части в объеме проекта. Например, затраты на персонал мо-
гут определяться числом сотрудников в каждом отделе, но другие затраты будут рассчиты-
ваться по пропорциональному соотношению затрат на непроизводственный персонал к за-
тратам на производственные ресурсы.
На совещаниях следует накопить как можно больше метрик. Как минимум, должны
иметься следующие данные:
 транзакционная информация — объемы, исполнители операции, время процессов;
 сопоставление транзакционных данных с уровнем выделяемых ресурсов на каждом
участке процесса с целью оценить обоснованность времени обработки и объемов, а также
целесообразность внедрения дополнительных процессов;
 прямые затраты на труд по каждому процессу, которые рассчитываются, исходя из
времени выполнения операций, транзакций процесса и коэффициента использования труда;
 затраты на ИТ и другие накладные расходы на процесс на основе ежедневного време-
ни выполнения операций.
Типовая матрица учета затрат показана на рис. 16.3.

Рассматриваемое подразделение осуществляет обработку транзакций только двух типов:

 выписывание квитанций – нет такого процесса на рисунке – С.К. на рисунке
«оприходование»
 обновление полисов.
Количество транзакций в день приведено на рис. 16.3, как и оценка времени выполнения
(в минутах) на транзакцию (процесс). Рассчитывается почасовая стоимость труда, а также
почасовые начисления, не связанные с трудом. Это дает возможность рассчитывать средние
затраты и затраты в годовом исчислении на трансакцию (процесс), исходя из 250 рабочих
дней в году.
 В зависимости от стандартного рабочего дня, взятого для расчетов, в таком сопоставле-
нии будут допустимы различные коэффициенты использования рабочего времени. Напри-
мер, если исходить из 7,5-часового рабочего дня, разумно взять коэффициент использования
от 80% до 85%. Если рабочий день в организации 6,25 часа, следует ожидать 100% исполь-
зования рабочего времени.
Примечание. Будьте осторожны с процентами, взятыми для проекта, и убедитесь, что
они восприняты в организации и согласованы с бизнес-подразделениями.
Метрики следует собирать на всех уровнях. Вот несколько полезных примеров (хотя не
предполагается, что все эти метрики будут собираться или использоваться).
Уровень матрицы выбора процессов:
1. Продажи и численность персонала на уровне бизнес-подразделения.
1. Разрез организации (объем и выручка продаж) по различным секторам бизнес-
подразделения и/или объему проекта.
2. Процентное разбиение объемов на уровне процесса и подпроцессов.
3. Стоимость выполнения такого объема транзакций для бизнеса (например, годовые
бюджеты).
Уровень процессов:
1. Определение измеряемых участков процесса (процессов).
2. Сбор оценок времени обработки по процессам или подпроцессам; если затраты могут
быть отнесены на конкретный процесс, это идеально; учет затрат по типам деятельности (ес-
ли он внедрен в организации, это может дать большой объем информации).
3. Определение мер функционирования процессов, например соглашения об уровне об-
служивания (SLA), основные показатели эффективности (KPI) и KPI подпроцессов.
4. Подробное описание того, как измеряется в данное время правильность процессов,
ведется ли мониторинг ошибок.
5. Измерения везде, где обнаруживаются «узкие места».
Примеры типов метрик, которые могут оказаться полезными:
 количество транзакций по методу оплаты или региону (ежемесячно за последние 8–12
месяцев, чтобы выявить тенденцию по месяцам или периоды наибольшего роста);
 время, затрачиваемое на главные процессы, особенно операции, для которых критич-
ны даты;
 количество ошибок и их типы;
 отчеты о невыполненной в срок работе, состояние и объемы (величины и количества)
— тенденции за последние 12 месяцев;
 объемы и стоимости различных типов транзакций;
 затраты на оплату труда по ключевым должностям, включая накладные расходы на
труд;
 отработанные сверхурочные часы/по договору подряда/временного найма — данные
за последние 12 месяцев;
 почасовые затраты, включая накладные расходы за сверхурочный труд;
 журнал жалоб — их число и тенденция за последние 12 месяцев (плюс анализ типич-
ных жалоб);
 мера переделок, процентная доля от объема транзакции, время и влияние на трудоза-
траты;
 стоимость списываемых ежемесячно транзакций за последние 12 месяцев;
 процентная доля времени, потраченного на процессы, не охватываемые объемом про-
екта.
Управленческий уровень:
1. Опросы удовлетворенности клиентов, которые могут дать весьма интересную инфор-
мацию.
2. Для получения показателей качества или эффективности воспользуйтесь следующи-
ми мерами:
 эффективность — каковы объемы ресурса, используемого для выполнения необходи-
мых действий;
 адаптивность — насколько легко осуществляются в организации перемены;
 общие знаменатели — время, финансовые и трудовые затраты, удовлетворенность
клиентов;
  коэффициент удержания клиентов по подразделениям и/или каналам дистрибьюторов
(за последние 12 месяцев, включая ежемесячные тенденции).
3. Исследования тенденций производительности.
4. Отчет по наличному персоналу согласно занимаемым должностям, в сопоставлении
со структурно-организационной схемой с целью выявления расхождений со штатным распи-
санием.
5. Копия отчета об измерении эффективности работы руководства за последние 12 ме-
сяцев.
6. Отчеты по ISO и/или аудиту, внутреннему и внешнему.
7. Уровень резерва для покрытия списаний.
8. Текучесть кадров за последние 12 месяцев.
9. Время пребывания сотрудников на должности.
Как собирать метрики?! Метрики можно собирать:
 в ходе практических совещаний;
 во время собеседований с руководством и сотрудниками при проверке информации,
полученной на практических совещаниях;
 по различным опросам и анкетированию;
 по управленческой отчетности.
Если трудно хронометрировать процессы во время практических совещаний моделиро-
вания, можно завершить моделирование процессов и провести еще пару практических сове-
щаний, чтобы пройтись по моделям с целью хронометража. Такая информация может иметь-
ся у других сотрудников организации. После этого данные экстраполируются, чтобы убе-
диться, что они осмысленны.
Например, расчетную таблицу, сформированную для умножения времени процесса на
количество совершаемых транзакций (чтобы высчитать итоговое время обработки) и экстра-
полируемую на «предполагаемое» количество сотрудников, можно сравнивать с «фактиче-
ским» количеством работников, занятых в процессах. По нашему опыту, если такая экстра-
поляция точна в пределах 15–20%, на данной фазе этого вполне достаточно. Нужно лишь
убедиться, что охвачены все процессы и операции.
Также необходимо понимать различные показатели работы исполнительного руковод-
ства, управленцев и руководителей коллективов, чтобы быть уверенным, что эти показатели
идут на пользу процессу, а не против него.
Помните, что главная задача сбора метрик на этапе понимания — определение точки от-
счета для сравнения с результатами этапа инноваций.
Шаг 5. Анализ истинных причин плохо работающего процесса
Весьма важно установить истинную причину проблемы или плохо работающего процес-
са. Если полного ее понимания нет, нельзя начинать этап инноваций, поскольку нет уверен-
ности, что реструктуризация процесса устранит проблему. Здесь прослеживается аналогия с
врачом, лечащим не болезнь, а симптомы.
Как лучше всего провести анализ истинных причин проблемы? Это зависит от конкрет-
ной организации. Практические совещания:
 в одних организациях сразу выведут истинные причины на поверхность,
 в других организациях группе проекта придется самой вникать в бизнес и самостоя-
тельно анализировать причины неудач.
В последнем случае требуется исследование, изучение, анализ, беседы с людьми, испол-
няющими процессы в повседневной работе. Не забудьте переговорить с сотрудниками, не
участвующими в конкретном этапе процесса, поскольку истинная причина может находить-
ся вне рамок нормального хода анализируемого процесса. Это еще один пример необходи-
мости сквозного изучения процессов, их прозрачности. В противном случае нельзя быть
уверенным, что «охвачены» все аспекты процесса. Хотя беседовать с руководством очень
важно, обычно ему неведома истинная причина проблемы (в зависимости от характера
ошибки).
При анализе истинных причин проблемы предлагается постоянно иметь в виду следую-
щие факторы:
 имеются ли источники ошибок или переделки выполненной работы;
 вызвано ли это другими процессами (процессом);
 правильно ли получается информация;
  если нет, что нужно сделать для выправления ситуации;
 достаточна ли квалификация исполняющего персонала для выполнения процесса;
 можно ли улучшить структуру используемых форм;
 есть ли в организации достаточный потенциал для доведения процесса до желаемого
стандарта;
 не простаивает ли персонал;
 приносят ли шаги — составляющие процесса пользу для требований заинтересован-
ных сторон и задач процесса;
 выполняются ли шаги в нужной последовательности.
Шаг 6. Заполнение матрицы способностей персонала
Матрица квалификационных способностей персонала дает полезную информацию и от-
носительно текущего и будущего состояния. Но будущее — самое главное. Если будущее
существенно отличается от текущей ситуации, для последней матрицу, возможно, заполнять
не стоит, разве что в целях понимания разрыва между квалификацией персонала организа-
ции на данный момент и необходимыми изменениями в будущем. В некоторых случаях ана-
лиз имеющейся квалификации может дать полезные сведения об истинных причинах кон-
кретных искажений процессов.
Анализ разрыва между тем, что есть, и тем, что должно быть, достаточно важен, и его
нужно зафиксировать и в общих чертах осознать на данной стадии. Лишь на этапах иннова-
ций и изменений персонала эти данные будут анализироваться значительно более детально,
и связываться с отдельными лицами, конкретными планами мероприятий и потенциальными
изменениями в организационной структуре.
На рис. 16.4 представлен пример заполнения такой матрицы. В строках показаны базо-
вые квалификационные навыки или компетенция, требуемые каждым процессом для выпол-
нения операций или определенной деятельности. По вертикали показана модель сквозного
процесса, группы процессов или индивидуальных процессов. Базовые навыки ранжируются
по простой шкале от 1 до 3, где 1 означает обязательные навыки, а 3 — желательные, но не
необходимые.

Требуемые квалифи- Способность

кационные навыки / знания продаж кли- общения Ввода дан- Справляться с
/ способности ентам ных привередливыми
Главные процессы клиентами
извещение 2 2 3 1
Оценка 1 1 3 1
Утверждение 3 2 3 1
Оплата 2 2 3 2
Завершение 2 3 1 1

Рис. 16.4. Типовая матрица способностей персонала. Воспроизведено с разрешения

MPM Group Pty Ltd, работающей под торговой маркой TouchPoint Process Management Ser-
vices
Не забудьте:
 оценить текущие способности под углом зрения будущих требований;
 на данной стадии проекта видеть картину в целом, а не на уровне отдельных сотруд-
ников;
 в общем виде рассмотреть распределение обязанности по каждому участку;
 рассмотреть требования к расширению базовых навыков сотрудников.
Шаг 7. Получение имеющейся информации
Цель этого шага — проанализировать имеющуюся на данный момент в организации ин-
формацию в рамках объема проекта. Данный шаг следует выполнять, только если это полез-
но внутри проекта. Лучше всего выявить имеющуюся информацию о процессах или знаниях
посредством практических совещаний и/или обсуждений с людьми из бизнес - подразделе-
ний, отделов работы с персоналом и обучения.
На практических совещаниях на этапе понимания можно разработать матрицу, по форме
похожую на матрицу выбора процессов. Пример приведен на рис. 16.5.
 Главные процессы, для которых заполняется матрица, показываются по вертикали. В
данном случае это сквозной процесс обработки требований о возмещении ущерба, включая
уведомление, оценку, утверждение, платеж и завершение. Типы знаний, уже имеющиеся или
желательные в организации, показаны в строках.
Знания обычно классифицируются по двум категориям:
1. недокументированные знания отдельных сотрудников, их образование и опыт (не на
бумаге).
2. Явно документированные знания в организации. Документация может быть знания-
ми, воплощенными в виде таких автоматизированных решений, как документооборот или
системы приложений.
После этого матрица заполняется примерно так, как показано на рисунке, где серые зоны
представляют недокументированные знания.
Особенно полезно четко выделить знания, полезные для процессов «идентификации» и
«приоритетных» процессов – нет на рисунке – С.К., т.е. наиболее ценных процессов.
В равной степени важно четко определиться с типом документации, необходимой для
удовлетворительного предоставления продуктов и услуг заинтересованным сторонам (внут-
ренним и внешним). Понятно, что чем больше явных процессных знаний (документирован-
ных или систематизированных), тем лучше, и тем менее вероятно, что это знание «уйдет»,
если уволится персонал.
Шаг 8. Определение приоритетов инноваций
Определение приоритетов инноваций должно стать результатом шагов моделирования,
сбора метрик и анализа коренных причин этапа понимания. На этих шагах должно стать
очевидным, какие участки бизнеса и процессы открывают возможности усовершенствования
и быстрых выигрышей.
Выстраивание приоритетов должно основываться на анализе, выполненном во время
практических совещаний, метриках, взглядах заинтересованных сторон и выбора действий
для каждого процесса. Приоритеты могут быть следующими:
 сохранение процессов (процесса) в существующем виде — они достаточно хороши;
 усовершенствование, что означает лишь необходимость мелких изменений или
настройки/отладки;
 объединение с другими процессами (процессом);
 перестройка — начиная с чистого листа;
 полное обновление — выйти за пределы привычного мышления и внести радикаль-
ные изменения;
  передача на сторону (аутсорсинг);
 выполнение процесса внутри организации (инсорсинг);
 исключение процесса.
При определении возможностей перестройки и быстрых выигрышей важно обеспечить
их соответствие и полезный вклад в задачи процессов, стратегические цели и ожидания за-
интересованных сторон, сформулированные на этапе архитектуры процессов. Потратьте
время на увязку или сопоставление возможностей с этими задачами, целями и ожиданиями.
В некоторых организациях, возможно, будет необходимо закончить бизнес-обоснование
(включая анализ затрат/отдачи и/или анализ экономической эффективности), перед тем как
руководство утвердит продолжение проекта. Завершенное обоснование можно получить, об-
новив разработанное ранее исходное обоснования проекта.
Шаг 9. Определение быстрых выигрышей
Как упоминалось ранее, в большинстве организаций настаивают, чтобы проекты совер-
шенствования процессов были самофинансируемы, так что необходимо найти пути дости-
жения быстрых выигрышей. Также рекомендуется, чтобы часть предложений быстрых вы-
игрышей исходила от сотрудников низшего звена — рядовых исполнителей процессов, даже
если такие выигрыши не сулят чего-либо значимого, потому что это будет означать, что вы
прислушиваетесь к рядовым исполнителям. Добейтесь, чтобы рядовые исполнители были
публично отмечены за идеи и успешную реализацию предложений быстрых выигрышей. Это
внесет серьезный вклад в ход изменений отношения персонала к проекту, необходимого в
любом проекте BPM.
Действия, которые необходимо осуществить на данной стадии проекта:
 вернуться к быстрым выигрышам на практических совещаниях, более детально убе-
диться в их целесообразности и выстроить очередность их реализации в порядке приоритета;
 проверить реализуемость быстрых выигрышей и их экономической эффективности
(т.е. убедиться, что стоимость реализации не превышает получаемых выгод), а также их
пользу и результативность в качестве бизнес-решений;
 оформить предложенные решения для утверждения заинтересованными сторонами
(внутренними и внешними);
 получить утверждение, окончательно сформировать и оформить более подробный
план разработки и внедрения быстрых выигрышей.
Следует обдумать целесообразность создания подпроектной группы по реализации
быстрых выигрышей. Такой шаг не отвлекает саму группу проекта от этапа инноваций.
Если быстрые выигрыши передаются для внедрения отдельной группе, основная группа
проекта не должна полностью отстраняться от реализации, перекладывать ответственность
на подгруппу, не участвуя в реализации быстрых выигрышей. На основной группе лежит
окончательная ответственность за их успех, потому что при появлении вопросов в связи с
неудачной реализацией предполагаемых выигрышей, описанных в обосновании или доку-
ментации, основную группу будут считать ответственной за это, даже если неудача была вы-
звана негодным внедрением. Основная группа проекта должна определять его объем, помо-
гать разработке графика проекта, обеспечивать качество проекта на всем протяжении срока
его существования, а также реализацию сформулированных выигрышей.
Шаг 10. Отчет
По завершении данного этапа группа проекта должна составить отчет для спонсора про-
екта, подводящий итоги и формулирующий конкретную отдачу. Отчет должен содержать
следующую информацию:
1. Цель этапа понимания.
2. Проблемы процессов, обнаруженные на практических совещаниях и во время анали-
за.
3. Перечень заинтересованных сторон и их связь с проектом.
4. Результаты:
o действующие процессы (процесс);
o метрики;
o выявленные быстрые выигрыши.
5. Предлагаемый порядок приоритета на этапе инноваций.
Реализация ценности
 Как часть этого этапа должны быть сформулированы эталонные точки отсчета и сравни-
тельные измерения. Подробно это описано в главе 21, шаг 3, в контексте реализации ценно-
сти в рамках проекта.
Конкретные итоги этапа понимания
Этап понимания дает ценный вклад в другие этапы общей схемы (рис. 16.6), включая
некоторые из следующих примеров:
 можно получить знания, которые будут полезны для архитектуры процессов при мо-
дифицировании или расширении стандартов или составлении методических руководств для
организации;
 разумеется, будет внесен вклад и в этап инноваций — отсчетные метрики, приорите-
ты инноваций и т.п.;
 будут результаты, способствующие потенциальному описанию новых должностей,
указания на то, что может потребоваться при разработке решений, а также способы распро-
странения решения по организации, например матрица способностей сотрудников.

Риски этапа понимания

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

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

2. затягиваются практические совещания тщательное планирование; соблюдение гра-

фика; адаптация плана по ходу этапа

3. слишком детальное моделирование на всегда иметь в виду цель этапа; подробное

практических совещаниях моделирование; не забывать спрашивать: о
возможности завершить моделирование

4. участники практических совещаний не обращение к бизнес - подразделению или к

понимают, как на деле функционируют спонсору проекта; замена участников прак-
процессы тических совещаний

5. излишне детальный анализ метрик определение приоритетов для этапа иннова-

Риск Содержание Способы снижения

ций и точки отсчета для сравнения с итогами

этапа инноваций

6. не собраны метрики заручится поддержкой спонсора проекта

Глава 17. Этап инноваций. Назначение

Цель этапа инноваций (рис. 17.1) — сделать процесс (процессы) в объеме проекта
насколько возможно эффективным и продуктивным, чтобы он отвечал текущим и будущим
ожиданиям заинтересованных сторон. Этот этап также дает уникальную возможность впо-
следствии более строго численно определить выгоды, указанные в исходном бизнес-
обосновании проекта.

«Зачем нужен этап инноваций и какова степень инноваций?» — это ключевой вопрос, и
ответ на него нужно дать еще до того, как приступать к выполнению этого этапа. Пол О’Нил
(Paul O’Neill), президент компании Alcoa, в письме к сотрудникам компании по всему миру в
ноябре 1991 года указывал:
Постоянное совершенствование — правильная концепция именно для мирового лидера
во всем, что вы делаете. Если вы утратили мировое лидерство, эта идея ужасна. Ну а если
вы далеки от мирового стандарта, она просто катастрофична, и вам нужен быстрый ка-
чественный скачок.
Нужно ли рассматривать возможность автоматизации как часть этого этапа проекта?
Еще одно замечание об автоматизации приписывается Биллу Гейтсу (компания Microsoft):
Правила любой технологии:
1. автоматизация эффективно выполняемой работы повышает эффективность;
2. автоматизация неэффективной работы увеличивает неэффективность.
Отладка процессов перед автоматизацией, определенно, должна рассматриваться как
приоритетная задача, что и было обсуждено в главе 3.
Постановка задач и выбор направлений — важнейший шаг этапа инноваций, который
должен выполняться на ранней его стадии. Это как включаться в новую игру — если не
знать правил игры до начала, трудно играть и выигрывать. Поэтому установить правила —
один из важнейших первых шагов этапа.
Результаты - различные документы, разрабатываемые на данном этапе:
1. Модели перестроенных процессов.
2. Поддерживающую документацию перестроенных процессов.
3. Общие бизнес-требования вариантов новых процессов.
4. Имитационные модели и подробный учет затрат по типам деятельности.
5. Информацию по планированию кадровых ресурсов.
 6. Подтверждение того, что альтернативы вариантов новых процессов будут отвечать
ожиданиями заинтересованных сторон.
7. Подтверждение, что варианты новых процессов отвечают стратегии организации и
будут решать поставленные перед процессами задачи.
8. Отчет по итогам анализа «разрывов» процессов.
9. Подробный план проекта на этапы изменения персонала и разработки.
10. Подробный анализ затрат и выгод и включение его в бизнес-обоснование.
11. Обновленное бизнес-обоснование с более подробными и количественно опре-
деленными выгодами и затратами, оценкой воздействия на организацию — нужно отразить в
нем материальные и нематериальные выгоды.
12. Подробный отчет с описанием предпринятых шагов, рассмотренных вариантов
и альтернатив, детальным анализом, выводами и рекомендациями.
13. Презентация руководству высокого уровня в поддержку бизнес-обоснования и
рекомендованного направления.
14. Первоначальный план информирования всех заинтересованных сторон и об-
щения.
Осуществление. Лучше всего разрабатывать варианты новых процессов и альтернативы
на практических совещаниях, которые отличаются по структуре и подходу от совещаний на
этапе понимания — это важно заранее понять и правильно их спланировать. На таких сове-
щаниях необходимо обеспечить фактическое сквозное выполнение перестраиваемых про-
цессов, и, если это означает пересечение границ подразделений и даже организационных
границ, то так тому и быть.
В сценариях «обычная работа», «рулевой» и «пилотный проект» совещания на этапе ин-
новаций не затрагивают существующей структуры организации; если ее нужно изменить,
посоветуйте это.
При подходе «вне поля зрения» изменить структуру организации и рекомендовать изме-
нения будет труднее.
Их следует рассматривать отдельно и позже - на этапе «изменения персонала».
Однако ключевой анализ для обеспечения входных данных для него требуется выпол-
нить здесь.
Одна из главных проблем предоставления информации о процессах — несоответствие
между обычной структурой организации (вертикальной или пирамидальной основы) и тем,
как поступает и выполняется «работа» (транзакции) внутри организации.
На рис. 17.2 показана обычная сложившаяся организационная структура.

Вертикальные линии разделяют подразделения, при этом исполнители процессов пере-

дают работу между разными подразделениями. Работа выполняется горизонтально, как на
рис. 17.3, проходя по различным подразделениям в рамках модели сквозных процессов орга-
низации.
 Именно точки передачи между подразделениями открывают наибольшие возможности
для усовершенствования процессов.
Задачи или показатели (основные направления результатов и показатели эффективности)
различных подразделений организации, и проходящая через них транзакция, могут противо-
речить эффективной и эффектной обработке транзакции. Это несоответствие — одна из
ключевых проблем для решения бизнес-группой и группой проекта.
Кейс: из автомобильной промышленности
Примеры традиционного и сквозного управления бизнес-процессами можно обнаружить
в процессе разработки новой модели автомобиля и организации процесса его изготовления.
Традиционный взгляд упрощенно заключается в том, что:
1. конструкторский отдел разрабатывает концепт-дизайн нового автомобиля
2. от инженерно-технологического отдела требуется разработать производственный
концепт и получить двигатель и другие комплектующие.
3. отдел снабжения привлекается к обеспечению поставок комплектующих, и
4. на заводе начинается производство.
В Японии (и небольшом количестве других производящих автомобили стран) принят го-
ризонтальный подход к этому процессу. Один человек поставлен во главе всего процесса: от
создания до производства новой модели. Это лицо отвечает за:
1. конструкторский дизайн,
2. технологическое обеспечение,
3. поставки комплектующих,
4. и т.д.
Оно реально контролирует сквозной процесс изготовления нового автомобиля. Это лицо
должно разработать «матрицу подчиненности», располагая полномочиями и неся ответ-
ственность за осуществление необходимых шагов.
Вывод. Управление процессами значительно более эффективно, если процессы рассмат-
риваются и управляются с точки зрения сквозного процесса.
Перед началом совещаний и запуском процесса (процессов) инноваций нужно задать во-
прос по существу: откуда мы знаем, что разработанное и предлагаемое для внедрения — это
именно то, что нужно клиентам/поставщикам/партнерам, чтобы получить высокий уровень
удовлетворенности и эффективности обслуживания. Остановимся на этом вопросе, потому
что если на него не ответить, проект не будет успешным, даже если удастся сократить затра-
ты или повысить качество.
На рис. 17.4 показано, как можно измерять уровни обслуживания и удовлетворенности
клиентов. Клиент может получить высокий уровень обслуживания, но все же не быть удо-
влетворенным.

Организации постоянно твердят о факторе возгласа «вау» (восхищения и удивленного

восторга), и о том, насколько им важно «превысить ожидания клиентов» и «приятно уди-
вить» их. Этот фактор может принимать форму особых характеристик продукта или неожи-
данного приятного сюрприза при обслуживании клиента. «Вау-факторы» могут быть чрез-
вычайно эффектны, укрепляя лояльность клиентов, при условии, что они не раздражены или
не раздосадованы. Раздражение клиента может иметь гораздо большее влияние на его мне-
ние об организации, чем «вау-фактор».
 Между зоной раздражения и зоной восхищения лежит еще одна зона, к которой не нуж-
но обращаться в проекте или бизнес - обосновании, если цели инноваций — улучшение об-
служивания и повышение удовлетворенности клиентов. Расходование средств на эту зону не
дает выгод для клиентов, и его нужно избежать.
Любопытно, что время, потраченное организациями на зоны восхищения и раздражения,
не пропорционально выигрышам, получаемым в них, как показано на рис. 17.5.

Кейс: процесс — это все

Один из авторов книги около года назад приобрел лэптоп хорошо известного крупного
изготовителя компьютеров. Когда сумка для ношения опять порвалась, и к изготовителю об-
ратились во второй раз, он превысил ожидания, подарив новую кожаную сумку в знак «доб-
рого расположения». Но при этом покупателю пришлось прождать на телефоне около полу-
часа, его несколько раз переключали от одного сотрудника на другого, затем было сказано,
что «менеджер» перезвонит на следующей неделе или чуть позже, что привело к значитель-
но большему раздражению, чем восторг от новенькой бесплатной сумки.
Вывод. Необходимо видеть разницу между отличным обслуживанием и удовлетворен-
ностью клиента. Плохое обслуживание может легко уничтожить эффект фактора «вау».
«Перевернутый» треугольник на рис. 17.5 показывает объем усилий, которые организа-
ции традиционно направляют на эти аспекты услуг. Часто организации тратят много време-
ни, пытаясь выделить себя (дифференцировать) на фоне других организаций посредством
включения «вау-факторов» в продукты и услуги. И наоборот, слишком мало времени тра-
тится на устранение факторов раздражения клиентов. Картина в точности обратна той, кото-
рая должна быть.
Если бы организации больше времени тратили на устранение факторов раздражения, то
они увидели бы, что уровень обслуживания и удовлетворенности клиентов повысился. В це-
лом, большинство факторов раздражения вызывается неверно функционирующими процес-
сами.
Рассматривая критически важные для успеха проекта факторы, необходимо провести ис-
следование для понимания описанного выше положения, чтобы содействовать правильному
выбору направления проекта и осознанию того, что если реализовать определенные измене-
ния процессов, повысится уровень удовлетворенности клиентов, что будет способствовать
их удержанию.
Перед тем как перейти к шагам этапа инноваций, отметим несколько важнейших эле-
ментов, которые необходимо рассмотреть на совещаниях:
 в проекте должны быть выделены все нестыковки в организационно-функциональной
структуре (схема организационных взаимосвязей и перечень моделей сквозных процессов
будут хорошим подспорьем);
 все альтернативы новых процессов в проекте должны быть разумны, практичны и
просты;
 проект должен обеспечить оправдание ожиданий заинтересованных сторон;
 должны быть прописаны все возможности автоматизации в проекте;
 должны быть рассмотрены и учтены все взаимозависимости с другими процессами и
подпроцессами.
 Чтобы на выходе данного этапа получить положительные итоги, нужно выполнить не-
сколько общих шагов (рис. 17.6).

Шаг 1. Обмен информацией. Нужно, чтобы заинтересованные стороны все время знали
объем этапа инноваций, были в курсе рассматриваемых вариантов и их статуса. Обмен ин-
формацией должен быть организован таким образом, чтобы вклад заинтересованных сторон
не потерялся в море деталей, а сами стороны всегда знали статус своего вклада. Если их
предложения не могут быть приняты, важно сообщить причины. Это также будет содейство-
вать большему пониманию заинтересованными сторонами целей бизнеса и выбора вариан-
тов, который сделала организация от имени проекта. Разработка начального плана обмена
информацией может помочь этому.
Шаг 2. Стартовое совещание с участием руководства. Начать данный этап следует с
совещания с участием спонсора проекта и других ведущих бизнес-руководителей, чтобы
определить и понять связь проекта со стратегией организации и задачами процессов, а также
перестраиваемой областью бизнеса. Некоторую основу для этого совещания дает информа-
ция, накопленная на этапе стартовой площадки. Необходимо обдумать порядок проведения
этого совещания уже в конце этапа понимания, чтобы избежать задержек в начале этапа ин-
новаций.
Как правило, на таком совещании есть одно ключевое лицо, являющееся главным заин-
тересованным лицом проекта. Именно его необходимо в первую очередь привлечь к приня-
тию решений на данном этапе.
Сроки. Именно на совещании с участием руководства на ранней стадии этапа инноваций
ставятся и решаются критически важные вопросы, относящиеся к срокам и рассматривае-
мым вариантам инноваций. Эти варианты и есть некоторые из «правил игры» этапа иннова-
ций, по которым будет вестись «игра». Важно привлечь одного-двух широкомыслящих со-
трудников, знающих до мелочей действующие процессы, которые участвовали в практиче-
ских совещаниях моделирования процессов на этапе понимания.
Задачи процессов. Обсуждая на совещаниях варианты инноваций, нужно четко сформу-
лировать задачи. Заметьте, что если единственным фокусом на данном этапе является сни-
жение расходов, то часто страдает качество. Это особенно характерно, если задача снижения
расходов поддерживается показателями функционирования, которые поощряют меры сни-
жения расходов. В результате складывается поведение, порождающее проблемы с каче-
ством, поскольку персонал, главы коллективов и руководство нацелены пропустить транзак-
цию через процесс насколько возможно быстро, чтобы сократить расходы. Это недально-
видный подход, потому что стремление к «скорости» приводит к снижению качества и росту
объема переделываемой работы, а это влечет рост расходов. Важно, чтобы люди на этом
этапе мыслили свободно, не ортодоксально. Тогда появится возможность быть лучше, быст-
рее и дешевле за счет разнообразных методов работы. Но группа руководящих управленцев
должна сформулировать свои требования и приоритеты.
Кейс: давление в пользу сокращения затрат на обработку
Учреждение по оказанию финансовых услуг в значительной степени не дотягивало до
показателей своего соглашения о качестве обслуживания (достигая лишь 50% от целевых
показателей), поэтому руководство и персонал посредством стимулов были мотивированы
увеличить пропускную способность. Чтобы обеспечить качество, была внедрена 100 - про-
центная проверка в надежде, что это решит имеющиеся проблемы.
В результате ухудшились показатели SLA (уровней обслуживания) и снизилось каче-
ство. Анализ проблем качества выявил противоречие между стремлением ускорить обработ-
ку и проверкой. Цель персонала отдела обработки была как можно быстрее обработать тран-
закцию, потому ожидалось, что возможные ошибки будут обнаружены уже при проверке.
Проверяющие же исходили из предположения, что обработчики все сделали правильно, так
что нужен лишь беглый взгляд.
Сами транзакции не были сложными, и на этапе обработки ошибки не должны были
случаться. Помимо этого система «рабочего потока» не содержала достаточно бизнес - пра-
вил, что лишь усугубляло проблемы качества.
Затраты на проверки составляли 24% всех затрат организации на обработку, но давали
малую отдачу. В общем, не доставало чувства «хозяина» и подотчетности, как у персонала
обработки, так и у руководителей подразделений.
Вывод. Прививая культуру, воспитывающую чувство «хозяина» и подотчетной ответ-
ственности, с поддержкой в виде обратной связи и соответствующих измерений производи-
тельности при адекватном вознаграждении, можно было получить огромный выигрыш в ка-
честве (и одновременно сокращение затрат), таким образом, вживляя в процесс качество.
С другой стороны, если ориентир — качество, то, вероятно, за ним последует и сниже-
ние расходов, поскольку при повышении качества сокращаются ошибки и объем переделок.

Чтобы определить задачи процессов, необходимо ответить на вопросы, перечисленные

ниже.
Стратегические:
1. Данный проект революционный (значительные инновации) или эволюционный? Вы
намерены двигаться мелкими шажками или осуществлять кардинальные перемены с исполь-
зованием технологий или без всяких технологий автоматизации? Ответы на эти вопросы су-
щественно изменят подход к этапу инноваций и его ожидаемые результаты.
2. Каким образом проект сопрягается со стратегией организации?
3. Как проект поддерживает планы на ближайшие один-два года?
Планирование:
1. Какова бизнес-подоплека данного проекта?
2. Цели данного проекта:
o устранить «узкие места» (болевые точки): и нынешние, и будущие;
o обеспечить способность внедрять новые продукты и услуги;
o улучшить обслуживание клиентов;
o сократить операционные расходы;
o снизить раздражение клиентов;
o повысить качество;
o обеспечить соответствие требованиям законодательства и нормативных актов.
3. Каковы конкретные задачи и меры эффективности процессов, связанные с данным
этапом? При проработке этих задач в центре внимания должен находиться клиент. Сравните,
что думает организация, и что думает клиент — могут быть несоответствия, так что такие
исследования играют важнейшую роль.
4. Располагаете ли вы необходимыми ресурсами, чтобы взяться за проект?
5. Что должно произойти в результате реализации проекта?
6. Повысит ли проект кадровый потенциал организации?
7. Каковы условия «непригодности» проекта?
 Ограничения:
1. каковы сроки работы: три, шесть, двенадцать или двадцать четыре месяца?
2. Какие барьеры и ограничения нужно ввести в этап инноваций (например, допускают-
ся ли какие-либо изменения в системе ИТ)?
3. Есть ли ограничения в управлении изменениями персонала или в плане человеческого
фактора?
Успех (некоторые из следующих вопросов уже рассматривались на этапе стартовой
площадки, в таком случае актуализируйте информацию вновь приобретенными сведениями):
1. как в организации станет известно, что проект вышел на намеченные промежуточные
итоги или полностью завершился?
2. Какие ваши действия при этом предполагаются?
3. Каковы ожидания от проекта различных заинтересованных сторон (внешних и внут-
ренних)?
4. Как определить, успешен ли проект? Критерии успеха проекта должны быть сформу-
лированы заранее, поняты и зафиксированы.

Приведем два примера задач процессов, сформулированных по итогам стартовых сове-

щаний с участием руководства. Различия весьма заметны, что связано со степенью зрелости
или готовности организации к реализации BPM (более подробно рассматривается в главе
27).
1. Кейс: департамент правительства. Организация в данном примере находилась на
низшей ступени зрелости BPM и была неспособна предугадать перспективы своего развития
через два года. Согласия и реализации мер можно было добиться всякий раз лишь на полу-
годовую перспективу. Не было устоявшейся репутации, успешного обеспечения продукцией,
так что присутствовала лишь слабая уверенность в успехе организации.
Мы прошли с этой организаций путь до того самого момента, в который было достигну-
то согласие, что в весьма ограниченном объеме проект системы «рабочего потока» и элек-
тронного представления документов будет распространяться на шестимесячный срок. Это
послужило основой, позволявшей организации реализовывать дальнейшие проекты разви-
тия, удовлетворившись уже выполненными внедрениями и подготовившись к следующим
«перспективам».
Вывод. Выбранные варианты должны согласовываться со степенью зрелости организа-
ций в сфере BPM и способностью реализации проектов.
2. Кейс: учреждение по оказанию финансовых услуг с высокой степенью зрелости в
области реализации BPM. В учреждении по оказанию финансовых услуг уже была внедре-
на система «рабочего потока», которая использовалась лишь на зачаточном уровне. На со-
вещании с руководством менеджеры четко поняли последствия полномасштабного внедре-
ния данной системы и выигрыш от нее.
Поэтому они определили три сценария, которые потенциально могли содействовать
разработке бизнес-обоснования и ставили организацию на путь «полноценного» внедрения
BPM:
1. шестимесячный проект быстрых выигрышей при минимальных изменениях системы.
2. Восемнадцать месяцев с полным внедрением BPM и системой электронного пред-
ставления документов.
3. Восемнадцать месяцев с расширением существующего рабочего потока, но без пол-
ного внедрения BPM и без системы электронного представления.
Формулировка трех этих сценариев сработала чрезвычайно удачно и в сочетании со зна-
чительными усилиями в области метрик дала отличные данные для продвижения и включе-
ния в бизнес-обоснование.
Вывод. По мере возрастания зрелости организации расширяется спектр имеющихся ва-
риантов и повышается их сложность.
Автоматизация. При рассмотрении возможных вариантов, имеющихся у организации и
проекта, автоматизация BPM, особенно автоматизация рабочего потока, часто выдвигается
как вероятный или желательный вариант.
Хотя автоматизация в определенных обстоятельствах может стать существенным пре-
имуществом, она не обязательно является самым главным аспектом улучшения функциони-
рования процессов. Единственный наиглавнейший аспект — концентрация на человеческом
факторе, т.е. формирование правильной культуры, мотивирование, ответственность, чувство
«хозяина», подотчетность, показатели производительности, обратная связь и вознагражде-
ния.
Большая шумиха вокруг BPM может привести к мысли, что ПО для рабочего потока и
соответствующих решений BPM может давать самые ощутимые выигрыши. Но хотя эти ре-
шения способны стать адекватным и выгодным инструментом, именно культурные и чело-
веческие факторы могут оказаться существенными ограничителями, если с ними работать
неправильно, и, наоборот, стать мощными средствами содействия при правильном к ним от-
ношении.
Даже с учетом, возможно, огромной полезности автоматизации в усовершенствовании
процессов, человеческие факторы проекта игнорировать нельзя.
Кейс: правительственный департамент и ограничения персонала
Организация взялась за внедрение системы рабочего потока и электронной обработки
документов. Система была закончена, хорошо показала себя в тестовом режиме и была
внедрена. Персонал возненавидел ее, отказывался пользоваться ею, так что реализация про-
валилась.
Не прилагались усилия по вовлечению персонала по ходу проекта. В ПО не было ничего
неправильного; просто проблемы управления изменениями персонала не рассматривались и
не решались. Никакие измерения производительности персонала до этого не производились,
и сотрудники не привыкли к отчетности, так что рассматривали внедрение как угрозу и отка-
зывались пользоваться системой. Система была брошена.
Вывод. Если не проработать проблемы с людьми, риск неудачи может быть очень вы-
сок.
Сверочный список достижений критериев и показателей успеха. Необходимо опреде-
лить и согласовать критерии успешности процессов до начала практических совещаний на
этапе инноваций, чтобы эти совещания отталкивались от согласованных и определенных
ожиданий заинтересованных сторон. При проведении практических совещаний всегда нужно
следить, чтобы предлагаемый процесс увязывался с итогами, ожидаемыми заинтересован-
ными сторонами, сверочным списком критериев успеха, основными показателями эффек-
тивности и производительности.
Подготовка практического совещания должна включать распространение всем участни-
кам следующей информации, выработанной ранее:
 картины процессов организации;
 схемы организационных взаимосвязей;
 модели сквозных процессов изучаемой в проекте бизнес-области;
 матрицы выбора процессов для изучаемой в проекте бизнес-области;
 перечня всех проблем и возможностей, разработанного на этапе понимания;
 перечня всех процессов по названию и функции;
 соответствующих метрик, связанных с обсуждениями на совещании.
Другая полезная информация, которую нужно иметь под рукой, включает:
 бизнес-планы
 бюджеты на текущий и последующий годы, а также
 состав портфеля проектов организации (для учета пересекающихся и взаимосвязан-
ных проектов).
Практическое совещание не должно длиться более одного дня, и по возможности, огра-
ничиваться одним днем, чтобы не уходить в сторону от главного фокуса внимания.
Итоги практического совещания. Как минимум, такое практическое совещание с руко-
водством должно задать четкое направление продвижения дальше (набор правил) для этапа
инноваций, включая:
1. понимание того, каким образом и в каких точках проект и новые процессы (процесс)
стыкуются со стратегией организации.
2. Документированное понимание предлагаемых или желаемых задач новых процессов
(процесса) и соответствующих измерений производительности процессов.
3. Согласованный перечень ограничений на процесс инноваций.
4. Согласованные перспективы — временные рамки для вариантов инноваций.
5. Согласованный «масштаб» проекта — является ли проект эволюционным или рево-
люционным.
 Если четко не прояснить хотя бы эти аспекты, итоги и успех проекта могут быть под
угрозой. Вы «вступите в игру», не зная или не полностью понимая правил (т.е. набираете ли
вы очки и движетесь ли в правильном направлении).
Шаг 3. Организация проекта
Этот шаг предусматривает краткое рассмотрение действующего плана проекта с целью
удостовериться, что в результате шага 2 к практическим совещаниям привлечены нужные
сотрудники из группы проекта и с точки зрения бизнеса. На следующем шаге поясняется,
какие категории людей следует привлекать к участию в различных практических совещани-
ях этапа инноваций.
Нужно обеспечить увязку всех требований проекта, описанных в плане (графике) проек-
та (см. Приложение C), со стратегией организации и задачами проекта, которые считаются
необходимыми по итогам совещаний с руководством. Согласованные сроки и подход (вари-
анты) этапа инноваций могут также оказать влияние на план проекта. Этот план подвергает-
ся пересмотру в результате ряда новых предложенных сценариев процессов, например, воз-
можно принятие решения о разработке новых вариантов процессов на три месяца, двена-
дцать месяцев, двадцать четыре месяца, варианты с автоматизацией и без автоматизации.
Шаг 4. Фокус-группы внешних заинтересованных сторон
Внешними заинтересованными сторонами считаются заинтересованные лица вне рас-
сматриваемого в данном проекте бизнес-подразделения / участка, в т.ч. другие заинтересо-
ванные лица внутри организации, но внешние по отношении к данному бизнес - подразделе-
нию/участку, а также внешние по отношению к организации заинтересованные стороны.
Перед проведением начальных практических совещаний часто полезно собрать вместе
соответствующие заинтересованные стороны в фокус-группы (группу), чтобы рассказать им
о предлагаемых планах и их предполагаемом участии в ходе проекта. Также следует задать
вопрос о действующих процессах (недостатках и проблемах), о том, как им видится ведение
бизнеса в организации, чтобы получить вклад заинтересованных сторон в перестройку про-
цессов.
На данной начальной стадии все обсуждения следует вести на общем уровне, а подроб-
ности должны накапливаться позже, после детальных совещаний по инновациям. Внешние
заинтересованные стороны должны снова привлекаться на более поздней стадии. Целью же
на данный момент является получение от них общего вектора направленности, а также пере-
дача им чувства сопричастности. Это часть управления взаимоотношениями с заинтересо-
ванными сторонами (см. главу 24).
Фокус-группы заинтересованных сторон должны также внести свой вклад в обсуждения
совершенства обслуживания клиентов и их удовлетворенности, проводимые на более ранних
стадиях.
Шаг 5. Стартовые совещания по инновациям
Это момент, когда проект переходит от анализа (выполненного на этапе понимания) к
творчеству (синтезу новых идей и инновационному творчеству). Однако следует быть осто-
рожным: подход, принятый для этапа инноваций, в большой степени зависит от заданных
ожидаемых результатов. Пытаясь усовершенствовать процесс, участники совещаний должны
быть уверены, что не ограничивают себя лишь решением текущих проблем процесса (если,
конечно, это не является четко поставленной задачей). Изучение текущих проблем ограни-
чивает кругозор мышления и сужает возможности инновации и/или перестройки процессов.
Формулировка вариантов на совещании с руководством задает тон отказу от этой огра-
ниченности и инновационному направлению. Варианты инноваций нельзя основывать на
состоянии, выработанном на этапе понимания, или на отдельных процессах.
Если вы намерены улучшить или перестроить процессы, важно формировать новые
творческие идеи. Если же предлагаемый результат — внедрение инноваций, творческий
процесс нельзя ограничивать внутренними идеями, он должен также вбирать внешние идеи
из различных отраслей и вполне радикальные мысли о структуре будущих процессов. Инно-
вации подразумевают пристрастный пересмотр действующей парадигмы и мышление, выхо-
дящее за пределы, принятые в данной отрасли.
Необходимо будет использовать знания, накопленные на этапе понимания, и пере-
осмыслить существующий подход к процессам. Естественный вопрос: есть ли более целесо-
образный подход к процессу и его выполнению? Может оказаться полезным анализ слабых и
сильных сторон. По крайней мере, он даст стартовую точку для начала обсуждений.
 Так какие же методы могут использоваться? Наилучший подход, безусловно — практи-
ческие совещания и обсуждения с бизнес - подразделением. Весьма продуктивным может
оказаться использование опытными посредниками BPM инновационных методов и творче-
ского подхода. По нашему опыту наилучшие результаты достигаются на этапе инноваций
при использовании внешних посредников со значительными познаниями и квалификацией в
области BPM. Причины приглашения таких посредников в том, что люди, привлеченные на
заседания и занятые в изучаемой сфере, не отягощены «багажом». («Внешние» в данном
случае означает либо посредников из самой организации, имеющих опыт BPM, но не рабо-
тающих в сфере бизнеса, которую эти инновации затрагивают; либо посредников вне орга-
низации. В последнем случае полезен опыт из других отраслей).
На практических совещаниях сначала сосредоточьтесь на формулировке комплекса
идей. Не увлекайтесь слишком детальной «фильтрацией» — это придет позже:
 охватите разнообразие идей, т.е. постарайтесь сформулировать как можно больше
идей (включая радикальные);
 охватите идеи креативного «правого полушария» мозга — включите способность
мыслить комплексно и всесторонне;
 не допускайте оценок — важно, чтобы ни посредник, ни участники совещаний не вы-
сказывали оценок идей, выдвигаемых на этой стадии; должна быть открытость ко всем вы-
двигаемым идеям;
 замечайте возможности — особенно за пределами рамок традиционного мышления
(«квадрата»);
 посмотрите на организацию под различными углами зрения: с точки зрения клиентов,
поставщиков, партнеров или конкурентов.
Следующие «переключатели» можно использовать для генерации потока идей:
 наделение сотрудников расширенными полномочиями для принятия самостоятель-
ных решений и объединения логически связанных задач, что сократит время ожидания;
 встраивание контроля качества внутрь процесса вместо проверки на выходе в виде
отдельной операции;
 технология обеспечивает доступ к информации из различных мест, так что персонал
может включаться в работу без необходимости физически иметь в наличии соответствую-
щий документ;
 способы связи можно более тесно интегрировать с ИТ, например персонал на местах
имеет доступ к актуализированной информации и резервированию с клиентских объектов;
 RFID (радиочастотный идентификатор) позволяет более экономично вести отслежи-
вание, например, следить за обработкой экспресс-отправок;
 самообслуживание — клиенты могут больше делать самостоятельно, принимая ответ-
ственность за правильность информации и сокращая расходы организации и ее усилия;
 не создавайте сложные модели процессов ради того, чтобы просто справиться с ис-
ключениями. Охватывайте только главное направление, а с исключениями работайте от-
дельно. Например, ипотечная компания смогла сократить время обработки 95% своих за-
кладных с трех недель до трех минут, просто исключив из строгого общего процесса обра-
ботки 5% сделок, не вписывающихся в общую схему и требующих существенных дополни-
тельных проверок;
 наличие информации в реальном времени. Например, расценки на авиабилеты сего-
дня формируются на основе наличия данных в реальном времени;
 интеграция процессов с поставщиками, партнерами и клиентами;
 отладка процессов таким образом, чтобы они легче поддавались индивидуализации
(специализированной настройке); например, в компании Dell весь процесс выстроен с ориен-
тацией на специализированную настройку;
 использование технологии агента для механизма наступления события в соответствии
с заранее описанной ситуацией. Например, клиенты определяют максимальную сумму, ко-
торую они готовы заплатить за авиабилет;
 работа с несколькими продавцами (поставщиками решений), чтобы разработать об-
щую ситуацию.
Проведите сначала «мозговой штурм», и накопите побольше идей. На дальнейших ста-
диях можно прийти к «сходящимся» пригодным решениям.
 Еще одна концепция, которую можно рассмотреть, и которая часто обсуждается органи-
зациями — это «лучшие практики». Если такие методы можно найти в отрасли, то для про-
екта это могло бы послужить отличной отправной точкой.
Некоторые общеизвестные практические методики включают модель eTOM (в отрасли
услуг связи) и SCOR (управление цепочкой поставок). Но нужно быть осторожным, потому
что практические методики нужно рассматривать целостно, а не как «сырую» модель про-
цесса или последовательности операций. Окружение процесса может быть столь же важным,
как и сам реальный «поток» процесса (или даже более важным). Это окружение включает:
культуру, замеры производительности, мотивацию людей, наделение персонала полномочи-
ями, бизнес-правила (свод правил ведения бизнеса), политику организации в различных сфе-
рах и т.п. Поэтому важно приспособить и настроить эти эталонные модели и практические
методики к конкретным целям и обстоятельствам организации. Эталонные модели должны
были рассматриваться на этапе архитектуры процессов.
Может оказаться весьма затруднительно и очень рискованно просто скопировать «по-
ток» процессов из лучшей практической методики, надеясь, что он автоматически выльется
в успех для данной организации.
Кейс: Toyota. Компания Toyota получила признание если не как самый эффективный, то
как один из самых эффективных автомобилестроительных концернов в мире. Многие другие
производители автомобилей осматривали сборочные заводы Toyota, видели «процессный
поток» и пытались имитировать его. Почему же Toyota остается лучшей?
Дело совсем не в копировании «процессного потока». У Toyota есть сложные комплексы
аспектов, связанные с методами производства в компании. У нее есть цели для клиентов, со-
трудников и самой себя, которые поддерживаются тщательно разработанными стратегиями
и программами непрерывного совершенствования. Это образ жизни Toyota и ее работников,
а не разовый проект.
Если другие производители автомобилей не смогут «полностью» сымитировать систему
и культуру, они не смогут скопировать «лучшие практические методы» Toyota.
Вывод. Лучшие мировые практики — вещь непростая, скопировать их трудно.
Завершив первый шаг, постарайтесь свести идеи в группы и начните применять крите-
рии оценки, разработанные и согласованные ранее. Здесь начинает применяться мышление
«левым полушарием». По мере сужения диапазона идей и вариантов формируйте их общее
принятие. Принимайте во внимание реалистичность вариантов, хотя бы на самом общем
уровне.
Более подробный анализ осуществимости выполняется на последующих шагах. Один из
основных задаваемых вопросов: «Каким образом эти идеи отвечают ожиданиям и потребно-
стям заинтересованных сторон?» Дело в том, что необходимо всегда быть уверенным, что
учтены идеи и варианты, высказанные на обсуждениях в фокус-группах внешних заинтере-
сованных сторон. Очевидно, что эти идеи и варианты должны также решать задачи процес-
сов, определенные на совещании с руководством.
При проведении практического совещания инноваций процессов может быть полезным
вести журнал вопросов и возможностей для записи проблем, с которыми нужно разобраться,
и возможностей, которые необходимо изучить. Этот журнал заполняется по протоколам со-
вещаний. Типовой журнал приведен в Приложении D – стр. 256.
Количество итераций или вариантов, разработанных для каждого процесса, зависит от
сроков, ограничений и «широты» охвата, согласованных на совещании с руководством. Ин-
формация об организации практического совещания приведена в Приложении E – стр. 258-
259.
Планирование совещаний с участием руководства. Временные рамки (перспективы),
связанные с каждым сценарием перестройки процесса на этапе инноваций, должны были
быть четко согласованы на совещании с руководством.
Если выбраны временные перспективы трех и двенадцати месяцев, то участниками со-
вещаний должны быть сотрудники из сферы бизнеса, владеющие детальным знанием про-
цесса. Участниками совещаний по перестройке в более долгосрочной перспективе должны
быть руководители высокого уровня, способные принимать стратегически ориентированные
решения — например, об изменениях в ведении деловой деятельности, системах - приложе-
ниях, об исключении из рассматриваемых вариантов различных способов платежей, введе-
нии новых способов платежей, а также решении вопросов относительно использования ор-
ганизацией новых каналов продаж.
Практические совещания по инновациям часто существенно отличаются от совещаний
этапа понимания, поскольку центр обсуждений переносится с регистрации текущего состоя-
ния (понимание) на творчество и инновации (этап инноваций). Это означает, что участники
совещаний — в основном, менеджеры и лица, принимающие решения.
Более детальные подробности порядка проведения практических совещаний по иннова-
циям приведены в Приложении E (стр. 259-265).
Потенциальные итоги. Каких результатов можно ожидать от совещаний инноваций?
Конечно, это зависит от конкретной организации, но мы приведем примеры получаемых
итогов.
Как только завершено (или практически завершено) изучение нового варианта процесса,
полезно провести контрольный прогон типа «что, если…» или даже создать прототип, если
требуется автоматизированное решение.
Кейс: существенное сокращение количества сотрудников, участвующих в процессах
Клиенту хотелось иметь два сценария для совещаний на этапе инноваций:
1. без автоматизации на шесть месяцев;
2. с автоматизацией на год.
Была разработана общая модель сквозного процесса, чтобы перейти от реагирования на
события к упреждающим действиям. Количество перестраиваемых процессов было 13, и во
время семинаров их объединили в 6 процессов. В данном примере усовершенствования из-
мерялись сокращением количества сотрудников, задействованных в процессах (см. табл.
ниже).
Исходное количество точек соприкосновения и достигнутое сокращение
Процесс Исходное количество точек Без автоматизации Автоматизация
соприкосновений

1. 53 23 (57%) 9 (83%)

2. 15 15 (0%) 1 (93%)

3. 46 46 (0%) 5 (89%)

4. 47 18 (62%) 17 (64%)

5. 4 4 (0%) 1 (75%)

6. 14 10 (29%) 1 (93%)
Причина использования понятия «точек соприкосновения» заключалась в том, что сро-
ки, отведенные для проведения семинаров, не позволяли уделить достаточно времени анали-
зу метрик — далеко не идеальная ситуация. Однако потенциальное сокращение количества
сотрудников, участвующих в процессах, было впечатляющим.
Хотя мы понимали, что измерение показателя «точек соприкосновения» необязательно
перейдет в экономию времени и затрат организации, оно показывало значительное сокраще-
ние объема обработки транзакции сотрудниками благодаря устранению дублирования. По-
скольку участвовавшие в процессах люди были высокооплачиваемыми профессионалами,
затраты и клиентское обслуживание действительно кардинально улучшились.
Вывод. Анализ, не сопровождаемый подробными метриками, трудно защитить в бизнес
- обосновании. Анализ «точек соприкосновения» показателен, но недостаточен для оправда-
ния финансирования. Всегда настаивайте на достаточном для детального анализа метрик
сроке.
Шаг 6. Наметки метрик будущих процессов
Завершив совещания и моделирование новых процессов, самое время удостовериться в
наличии общего понимания возможных операционных затрат на эти новые процессы, а за-
тем сверить их с бизнес-обоснованием. В этот момент нужно также проверить, есть ли до-
полнительные выгоды и возможности для бизнес-подразделений.
 Анализ метрик не связан с анализом затрат/выгод в бизнес-обосновании или расчетом
стоимости внедрения новых процессов. Здесь речь идет о потенциальных постоянных опе-
рационных затратах для бизнеса.
Один из возможных подходов к такому расчету затрат:
 посвятить одно или несколько совещаний обсуждению предполагаемого времени
прохождения каждого нового процесса отдельно. Также следует
 рассмотреть действующие процессы, время их выполнения и, если целесообразно,
 сравнить их с новыми процессами, чтобы облегчить определение ожидаемого време-
ни исполнения процессов.
Если действующие процессы и время их исполнения неприменимы к существующей си-
туации, нужно оценить предполагаемое время исполнения процессов. В этом иногда помога-
ет имитационное моделирование. Использование минут в качестве общего показателя для
измерения метрик процессов поставит во главу угла основную цель.
Следующий шаг — экстраполяция предполагаемых будущих объемов транзакций. Если
рассматриваемый вариант рассчитан на 18 месяцев, то бизнесу нужно оценить любое увели-
чение или снижение объема транзакций по процессам.
Предполагаемое время исполнения процессов затем умножается на будущие объемы
транзакций, чтобы получить итоговое количество минут обработки. Это можно сделать, за-
полнив типовой шаблон, представленный на рис. 16.3 (матрица затрат — см. главу 16).
Далее наступает очередь бюджета подразделения. Прогноз бюджета исправляется, что-
бы можно было рассчитать затраты по различным выбранным вариантам сценариев иннова-
ций:
1. на основе новой загрузки ресурсов оценивается количество штатных сотрудников и
новые расходы на персонал (общая зарплата нового числа штатных сотрудников). «Другие
затраты на персонал» рассчитываются исходя из средней штатной численности на пропор-
циональной основе.
2. Размер других бюджетных затрат обсуждается, чтобы определить, на что повлияет
изменение общей штатной численности сотрудников. Эти затраты рассчитываются пропор-
ционально новой штатной численности. Остальные пересчитываются в соответствии с вход-
ными данными от бизнеса.
3. Оцениваются текущие и прогнозируемые затраты на ИТ. Автоматизированное реше-
ние BPM могло бы увеличить затраты ИТ, но если оно отлажено экономически, эти затраты
только снизятся. Это происходит, если неэффективные и дорогостоящие в обслуживании си-
стемы заменяются улучшенными более экономичными решениями.
Уровень моделирования процессов и пересчета объемов транзакций и имеющегося вре-
мени определит точность отнесения затрат на статьи.
Таким образом формируется новый прогноз бюджета, который используется в анализе
метрик затрат будущих процессов.
Кейс: учреждение по оказанию финансовых услуг
Движущие силы инновационных процессов в этом случае были следующими:
 неспособность достичь предусматриваемого уровня обслуживания;
 проблемы с качеством;
 неспособность обеспечить стратифицированные уровни обслуживания.
Следуя общей схеме и подробно проанализировав метрики, в организации поняли, что
поэтапное внедрение BPM и электронное представление документации даст сокращение
ежегодного операционного бюджета на 40% и сокращение штатного персонала на 45%.
Вывод. Без детального анализа метрик было бы трудно количественно определить по-
тенциал сокращения бюджета и дать достаточно подробный анализ для обоснования (в части
выигрышей), чтобы оправдать дальнейшее движение.
Шаг 7. Имитационное моделирование
Имитационное моделирование — это один из методов определения реализуемости и эф-
фективности предлагаемых вариантов перестроенных процессов. Имитация также может
применяться для проверки логики и согласованности процессов перед их внедрением. Это
требует значительных усилий и не должно недооцениваться или выполняться без должного
усердия. Чтобы провести имитацию, потребуется собрать необходимые метрики и сделать
предположения. Имитация полезна для проверки различных сценариев: спрос удвоится или
учетверится? Увеличивать ли число сотрудников, занятых на одном конкретном участке
процесса? Следует «прогнать» различные сценарии, чтобы проверить соответствующие мет-
рики и предположения.
После этого оцениваются «имитационные прогоны», и выполняется раздельный учет за-
трат по типам деятельности и оценка планирования персонала. Это поможет при определе-
нии измерений производительности вариантов процессов.
На этой стадии ко вариантов должно быть сокращено до набора наиболее целесообраз-
ных, и именно отобранные варианты должны стать предметом обсуждений на совещаниях с
различными заинтересованными сторонами на следующем шаге. Имитация позволяет, и да-
же требует, делать много предположений и допущений (например, частотность и распреде-
ление спроса, эффективность использования рабочего времени, количество ошибок и т.п.).
Необходимо документировать все такие предположения и предъявить их заинтересованным
сторонам, включая условия, в которых эти предположения делались.
Предлагаемые решения (вместе с обосновывающими доказательствами) следует офор-
мить документально, а модели процессов окончательно завершить для раздачи перед следу-
ющими совещаниями. Подробное описание встраивания «имитационного прогона» в этап
инноваций приведено в конкретном типовом примере - Приложение E – стр. 263-264.
Шаг 8. Обновление матрицы способностей персонала
На шаге 6 этапа понимания подчеркивалась необходимость заполнения матрицы спо-
собностей персонала. Эту матрицу (см. рис. 16.4) нужно пересмотреть или сформировать
для будущих новых процессов (процесса). Затем собранные сведения будут использованы на
этапе работы с персоналом в сравнении с текущей матрицей способностей персонала, сфор-
мированной на этапе понимания. Выполняется также анализ пробелов (разрыва между име-
ющейся и требуемой квалификацией) в применении к отдельным должностям с конкретны-
ми планами действий (обучение, переподготовка или повышение квалификации) и в связи с
потенциальными изменениями структуры организации.
Шаг 9. Планирование персонала может быть полезно с двух различных точек зрения:
 должно обеспечить наличие в нужное время нужного числа сотрудников, имеющих
необходимую квалификацию, чтобы удовлетворить потребности клиентов и организации:
 даст входные исходные данные для постановки задачи измерения показателей произ-
водительности, которые формулируются на этапе изменения персонала для отдельных со-
трудников, групп и руководящего состава.
Чтобы не слишком углубляться в детали, обратитесь к типовому конкретному примеру в
Приложении Е – стр. 264., который показывает, каким образом планирование персонала увя-
зывается с имитационным моделированием, учетом затрат по типу деятельности и распреде-
лением работ.
Шаг 10. Обсуждение предлагаемых решений на совещаниях
Группа проекта должна сузить варианты процессов до небольшого количества, и цель
следующей серии практических совещаний — объединение всех заинтересованных сторон,
чтобы определить, отвечают ли предлагаемые варианты всем их запросам. Среди заинтере-
сованных сторон должны быть представлены:
 бизнес-подразделения;
 внешние заинтересованные стороны (каналы распределения, поставщики, возможно,
инвесторы);
 персонал обеспечения действующего законодательства;
 информационные технологии;
 контроль операционных рисков;
 внутренний аудит;
 внешний аудит, в зависимости от процессов (возможно).
Здесь предоставляются документально оформленные варианты процессов вместе с ито-
гами различных имитационных прогонов, сценариями учета затрат по типам деятельности и
другими подтверждающими доказательствами.
Не все заинтересованные стороны, вероятно, следует объединять в одном совещании из-
за возможно противоречивых требований.
Постоянно ведется спор, следует ли строить процесс вокруг требований аудита, соблю-
дения законодательства и контроля операционных рисков. Мы предлагаем изучить макси-
мально эффективную и продуктивную перестройку процесса, чтобы он отвечал главным за-
просам бизнеса и основных заинтересованных сторон, а затем на втором заходе учесть тре-
бования аудита, соответствия законодательству и контроля операционных рисков. Аудит,
соблюдение законодательства и контроль рисков не должны быть движущими факторами
перестройки процессов, но их нельзя и игнорировать: организация просто должна выполнить
эти требования. Другой подход — описать бизнес-правила с точки зрения аудита, соблюде-
ния законодательства и контроля рисков и попытаться включить их в ходе перестройки про-
цесса.
Мы настоятельно рекомендуем привлечь бизнес-подразделения и ключевых заинтересо-
ванных сторон к участию в совещаниях, чтобы обеспечить соответствие перестроенных про-
цессов их запросам, и убедиться, что процессы не будут принципиально изменены в резуль-
тате конкурирующих требований. Только после того как этого удалось добиться, можно
включать внутренних и внешних аудиторов, сотрудников по соблюдению законодательства
и контроля операционных рисков.
Но иногда именно требования соблюдения законодательства или контроля операцион-
ных рисков выступают подспудными движущими силами процессного проекта.
Нам приходилось наблюдать это в некоторых банках, где именно подразделения соблю-
дения законодательства и контроля операционных рисков предоставляли начальное финан-
сирование в силу внешних обстоятельств (закон Сарбанеса-Оксли). Как только эти требова-
ния удовлетворены, бизнес-подразделения могут проявить интерес к исходному проекту и
расширить его в направлении совершенствования BPM.
Итог таких совещаний — достижение согласия и утверждение вариантов новых процес-
сов, чтобы перейти к шагу проверки реализуемости и осуществимости.
Шаг 11. Доказательство и проверка практической реализуемости предлагаемых
решений
Чтобы удостовериться в реализуемости и практичности вариантов перестройки, необхо-
дим дополнительный анализ, отвечающий на два вопроса:
1. Может ли новый процесс поддерживаться с точки зрения ИТ?
2. Будет ли бизнес функционировать эффективно и продуктивно в результате нового
процесса?
Если новый процесс:
 должен автоматизироваться, хорошей идеей часто оказывается построение демон-
страционной версии или прототипа предлагаемого процесса. Поставщики решений называют
это «промышленным образцом»;
 осуществляется вручную, следует провести «контрольный прогон» совместно с биз-
нес-подразделением.
При демонстрации автоматизированных образцов или проведении «контрольных прого-
нов»:
 попросите тестирующих сотрудников показать исключения. Этому может поспособ-
ствовать разыгрывание ролей.
 Не забывайте возвращаться назад и оценивать новые варианты в сравнении с задача-
ми процессов, согласованными на начальных совещаниях.
В результате этого шага может оказаться необходимым вернуться на шаг совещаний по
инновациям, если обнаружится, что некоторые аспекты процессов не реализуются или не-
практичны.
Шаг 12. Анализ разрыва процессов
Чрезвычайно полезно провести анализ разрыва процессов на этапе понимания и иннова-
ций. Дождавшись, пока будет выбран вариант процесса на шаге 10 и 11, можно избежать
разработки нескольких версий этого документа. Цель данного шага — сравнение новых и
старых процессов для бизнес-подразделения, подразделения ИТ и разработчиков учебных
материалов. Анализ разрыва процессов должен охватывать следующие моменты:
 краткий обзор действующих процессов;
 краткий обзор новых перестроенных процессов;
 основные изменения между двумя этими состояниями;
 проблемы процессов;
 соответствующие метрики;
 замечания по воздействию бизнеса и процессов;
 новые (бизнес) возможности;
 требуемые изменения (например, в ИТ).
 Анализ разрыва процессов должен содержать замечания по обучению, безопасности и
охране труда, по вопросам организационной структуры, а также помогать в некоторых ас-
пектах управления изменениями проекта. Пример анализа разрыва также приведен в Прило-
жении Е – стр. 265.
Шаг 13. Определение выигрышей и обновление бизнес-обоснования
Исходное бизнес-обоснование, разработанное на этапе стартовой площадки, определя-
ет некоторые из предполагаемых выгод.
На этапе инноваций проекта после окончательного оформления вариантов перестройки
процессов будет получена более подробная информация, дающая возможность спрогнозиро-
вать выигрыш более определенно.
На этом этапе должно быть возможно сделать значительно более законченное обоснова-
ние благодаря выполненной имитации, учета затрат по виду деятельности и метрикам: выиг-
рыш (например, улучшенные процессы) и затраты (например, на внедрение) уже более точ-
ные и просчитанные. (Иногда все же трудно провести оценку затрат на данной стадии проек-
та. Как только определены варианты новых процессов, и проект переходит к этапу разработ-
ки, затраты на разработку и реализацию можно рассчитать точнее).
Вновь рассчитанные затраты и метрики можно будет сравнить с метриками, собранными
на этапе понимания. Сравнение двух этих наборов метрик даст количественную оценку вы-
игрыша от перестроенных процессов, что представит более весомые доказательства бизнес-
обоснования (например, рис. 21.5).
Более того, бизнес-обоснование должно быть нацелено на «мягкое» внедрение и переход
от проектного состояния в режим повседневной деятельности. Насколько возможно, в него
также следует включить известную информацию о предлагаемом новом операционном ре-
жиме и влиянии на персонал.
Шаг 14. Отчет и презентации
На данном шаге разрабатываются отчеты и/или презентации в поддержку бизнес-
обоснования, представляемые на утверждение руководству высокого уровня. Разумеется,
важно добиться утверждения, и необходимо приложить все усилия для такой разработки.
Презентация должна быть спланирована (на начальном этапе обмена информацией на нее
необходимо установить срок) и нацелена на руководство или должностных лиц высокого
уровня.
Цель отчета — описать состояние проекта, полученные результаты и рекомендации эта-
па инноваций; отчет должен сопровождаться профессиональной презентацией. Это возмож-
ность для группы и спонсора проекта убедить руководителей высокого уровня в разумности
рекомендаций, чтобы продолжить финансирование (если оно еще не утверждено).
Шаг 15. Утверждение
На этом шаге организация утверждает рекомендованные варианты. В каждой организа-
ции существует свой порядок утверждения бизнес-обоснования, и это нужно прояснить и
учесть на этапе стартовой площадки проекта.
Шаг 16. Бизнес-требования
Выработка бизнес-требований — просто дальнейшее развитие документации, обеспечи-
вающей модели процессов. Бизнес-спецификации должны передаваться на этап разработки.
Возможно их предоставление отдельной группе внедрения, если требуются изменения или
разработка систем.
У каждой организации свои методы и документация, поэтому мы предлагаем не опреде-
лять их на данной стадии. Достаточно сказать, что документация должна быть написана с
точки зрения бизнеса и процессов.
В Приложении E (стр. 268, п. 9) дается описание конкретной организации, которая по-
дошла к существенным изменениям методов ведения своей деятельности, изменив бизнес-
процессы и ощутимо сократив операционные затраты, используя описанные в данной главе
действия.
Об успехе этапа инноваций будут судить не по стандарту моделей процессов (следуют
ли они согласованной архитектуре бизнес-процессов организации и соглашениям о моделях)
и не по эффективности или результативности моделей процессов «на бумаге», а по степени
их трансформации в реализованные процессы. Создание моделей новых процессов может
быть захватывающим упражнением, но пока они не превратились в реализованные, эффек-
тивные, результативные и адекватные процессы, дающие ценностный вклад в стратегию ор-
ганизации, цели и пользу всем заинтересованным сторонам, они остаются «интересными»
игрушками. (В данном контексте «реализация» означает принятие проекта исполнителями,
руководством, клиентами и остальными заинтересованными сторонами, т.е. экономичность
внедрения.)
Реализация ценности. В ходе этого этапа должен уточняться и оптимизироваться ком-
плекс выгод. Подробно это описано в главе 21, шаг 3, в контексте реализации ценности в
рамках проекта.
Конкретные итоги этапа инноваций

Этап инноваций вносит серьезный вклад в другие этапы общей схемы (рис. 17.7), и мы
приведем лишь несколько примеров:
 могут быть получены знания, полезные для этапа архитектуры процессов при мо-
дификации или расширении стандартов или методических руководств организации;
 могут появиться варианты обратной связи стратегической модификации организации,
например, реализации процессов самой организацией (инсорсинг), если организация достиг-
ла в них операционного совершенства;
 дальнейшие знания о структурировании должностных функций появятся на этапе
изменения персонала;
 инновации — это главные входные данные для этапа разработки, они дают расши-
ренный круг идей в области реализации предлагаемых изменений.
Риски этапа инноваций. Данный этап дает возможность осуществить инновационные
изменения, однако имеется ряд рисков, которые необходимо иметь в виду. Нужно реализо-
вать стратегии, устраняющие или снижающие их. Некоторые из этих рисков указаны в табл.
17.1.
Таблица 17.1. Риски этапа инноваций и способы их снижения
Риск Стратегия снижения

1. Нет уверенности в том, с чего Следуйте описанной общей схеме

начать

2. Организация излишне амбициозна Шаг 2 — совещание с руководством должно

и слишком распыляется (т.е. пытается сформулировать практические задачи процес-
провести слишком много изменений сра- сов BPM и сценарии. Опытные внешние по-
зу) средники часто могут обеспечить практичность
объемов без угрозы внутренних противоречий

3. Выбрано слишком много вариантов Шаг 2 — совещание с руководством должно

инноваций, например, 3-, 6-, 12- и 24- сформулировать практические задачи процес-
месячные варианты с автоматизацией и сов BPM. Опытные внешние посредники часто
без нее могут обеспечить практичность объемов без
Риск Стратегия снижения

угрозы внутренних противоречий

4. В организации отсутствует видение Этап стратегии организации дает направление

этапа инноваций, и она не способна опре- данного этапа, однако именно шаг 2 (практиче-
делить задачи процессов ское совещание) обеспечивает подробности. И
снова опытный посредник сможет помочь пре-
одолеть этот риск

5. Слишком узок объем этапа иннова- Объем первоначально определяется на этапе

ций стартовой площадки, и далее уточняется на
этапе инноваций на шаге 2 — практическом
совещании с руководством

6. Не учтены ожидания и запросы за- Шаг 4 играет важную роль в определении ожи-
интересованных сторон даний и запросов заинтересованных сторон, на
шаге 10 (обсуждение на совещаниях предлага-
емых решений) и шаге 11 (доказательство и
проверка практической реализуемости предла-
гаемых решений) следует снова вернуться к
этим ожиданиям

7. Инструмент BPM (или его постав- Бизнес должен возглавлять деятельность по

щик) руководит этапом инноваций, что инновации процессов, возможно, благодаря
приводит к неоптимальной поддержке возможностям, которые открывает инструмент
бизнеса BPM

Глава 18. Этап работы с персоналом. Назначение

Этап работы с персоналом (рис. 18.1) — наиважнейший этап реализации любого проекта
BPM, и если его не выполнить тщательно и на самом высоком уровне, это может поставить
под угрозу всю оставшуюся часть проекта. Важно четко понимать отличие данного этапа от
этапа внедрения, в фокусе которого находится развертывание выбранного решения. Как пра-
вило, этап работы с персоналом идет одновременно с этапом разработки, на котором форми-
руется решение с автоматизацией (или без нее); на этапе работы с персоналом происходит
распределение должностных обязанностей и принимаются решения для оценки функцио-
нальных характеристик персонала.
Цель данного этапа — сделать так, чтобы работа сотрудников, исполняющих новые
процессы, согласовывалась с задачами процессов и организации в целом, определенными на
предшествующих этапах проекта.
Именно люди делают функционирование процессов продуктивным и эффективным,
сколько бы ни автоматизировать процессы. Если сотрудники не прониклись проектом и но-
выми процессами, то они найдут способ сделать так, чтобы процессы либо не работали,
либо работали неэффективно.
Примечание
Хотя это утверждение справедливо, оно должно быть приведено в соответствие с ком-
мерческой реальностью. Это будет рассмотрено на шаге 4 в данной главе.
На данном этапе определяются функции персонала и руководства и вновь создаются или
пересматриваются должностные обязанности. Также изменяется или разрабатывается способ
измерения и управления показателями их производительности, отвечающий задачам процес-
сов и организационной структуре. Данный этап открывает для организации возможность
сделать должностные функции более интересными и повысить трудоспособность персонала.
Это относится не только к возможности занимать определенные должности внутри органи-
зации (т.е. способности людей выполнять различные функционально-должностные обязан-
ности, продолжать работать в организации на различных должностях), но и к внешней тру-
доспособности (повышая уверенность персонала в случае сокращений или аутсорсинга).
Итоги данного этапа должны работать — неудача недопустима. Его нельзя рассматри-
вать механически, как некоторую последовательность шагов, которые проект должен просто
пройти; группа проекта должна посвятить ему столько времени, сколько необходимо для
успешных результатов.
Результаты. Как узнать, что этап завершился успешно? По реакции людей на измене-
ния, смену функциональных обязанностей, новые процессы, управление эффективностью
выполнения должностных обязанностей и измеряемые целевые показатели. Несомненно, на
этом этапе рождаются некоторые документы и выполняются некие действия, но в конечном
итоге именно поведение людей покажет, были ли этап успешен.
Некоторые действия, совершаемые на этом этапе, и отчеты по его результатам включа-
ют:
1. разбиение и объединение новых процессов и операций, их составляющих, в типы дея-
тельности.
2. Пересмотр должностных инструкций и функций, которые обговаривались и согласо-
вывались с их предполагаемыми исполнителями.
3. Показатели и управление производительностью для соответствующих должностей,
что также обсуждалось и согласовывалось с предполагаемыми кандидатурами.
4. План и комплекс действий, обеспечивающих переход организации из теперешнего
состояния в новое. Это подразумевает полное и детальное понимание ключевых способно-
стей и квалификационных характеристик персонала на должностном уровне, а также накла-
дывается на выполненный ранее анализ разрывов процессов, что дает возможность разрабо-
тать планы обучения для групп и отдельных работников.
5. Новая основанная на процессах организационная структура бизнеса.
Осуществление. Многие организации и менеджеры скоры на руку и любят покритико-
вать и возложить на персонал вину за недостаточную производительность труда в организа-
ции. По нашему опыту, за редкими исключениями, это не вина рядовых исполнителей про-
цессов «в цехах». Подход организации к программе совершенствования должен придержи-
ваться такой последовательности:
1. процессы — сделать процессы эффектными, эффективными и дающими ценностный
вклад в стратегию организации.
2. Структура — отладить организационную структуру и должностные обязанности так,
чтобы они поддерживали новые процессы.
3. Люди — только после осмысления и выполнения структурных и процессных преобра-
зований можно приступать к оценке производительности персонала.
…если высокая производительность накладывается на негодную систему, система по-
чти всегда побеждает. Кин [39]
 Во всех организациях, которые мы консультировали за многие годы, мы большей ча-
стью видели, что исполнители — нормальные люди, изо всех сил старающиеся работать
как можно лучше с системами и процессами, которыми их обеспечило руководство. Во мно-
гих случаях сотрудники работают прекрасно, посвящая долгие часы специальной работе с
клиентами. В обязанности руководства входит обеспечить своему персоналу режим и ин-
струментарий (процессы, инфраструктура, системы), чтобы исполнители могли выпол-
нять свои функции эффективно и производительно.
На уровне проекта для выполнения согласованных задач процессов организации нужно
распределить должностные обязанности для поддержки процессов и подпроцессов и обеспе-
чить структурирование производственной среды, дающее возможность персоналу сделать
свой вклад максимальным.
Даже если организация оптимизировала структуру, процессы и операции выполняются
людьми. Без людей ничего не происходит.
Этап работы с персоналом проекта охватывает:
 решение о способе выполнения этапа;
 формирование типов деятельности;
 распределение должностных функций или обязанностей;
 определение показателей производительности персонала, исполняющего процесс
(процессы);
 определение измерений показателей сотрудников — исполнителей процесса (процес-
сов);
 обеспечение управляемости «стыков» между процессами, чтобы не было разрывов.
Это предполагает выделение достаточных ресурсов, чтобы люди могли работать эф-
фектно и эффективно.
Шаги этапа работы с персоналом показаны на рис. 18.2.

Шаг 1. Обмен информацией / общение

Поскольку этот этап замкнут на людей в организации, ясно, что лучше всего привлечь
их к процессу и информировать о нем. Будьте готовы к следующим вопросам:
1. что предлагается?
2. Как это будет осуществлено?
3. Как это отразится на мне?
4. Что я могу внести в результаты?
5. Что если мне не понравятся результаты?
Это лишь некоторые вопросы, на которые нужно дать ответ. Группа проекта должна
обеспечить инициативный подход к общению с бизнесом и затронутыми людьми.
Шаг 2. Разработка стратегии работы с людьми
Хотя группа проекта должна взять на себя ответственность за выполнение данного шага,
отдел кадров организации должен в значительной степени привлекаться к стратегическим
разработкам и планированию подхода к этапу работы с персоналом (кадровая стратегия).
Однако роль отдела кадров зависит от выбранного сценария проекта BPM. При осуществле-
нии сценария «вне поля зрения» это может отразиться на способе привлечения отдела. Дан-
ная стратегия должна учитывать практические методы работы и ограничения отдела кадров.
Если в организации существует профсоюз или совет работников предприятия, это суще-
ственно отразится на подходе к данному этапу.
Согласованная кадровая стратегия должна быть документально оформлена и утверждена
соответствующими заинтересованными сторонами, среди которых могут быть: руководство
и ведущие сотрудники, профсоюзы, сами работники и, возможно, даже клиенты и поставщи-
ки. Неразумно проводить реорганизацию, которую не поддержат клиенты или поставщики.
Кейс: раздувание объема проекта приводит к нехватке человеческих ресурсов
Нас пригласили в качестве консультантов в организацию, которая начала вносить мел-
кие усовершенствования в процессы. По ходу проекта мы обнаружили, что эта организация
находила все новые и новые возможности усовершенствования путем реструктурирования и
изменения действующих процессов, которые она начала реализовывать.
Хотя предлагаемые изменения были оптимальными, в них полностью игнорировался че-
ловеческий фактор, а объем проекта увеличивался. В результате менеджер по персоналу ока-
зался настойчивым противником внедрения новых процессов, поскольку они подрывали ос-
новные принципы, сложившиеся в отделе на протяжении десяти последних лет. Так что про-
цессы пришлось переделывать с учетом этих основных принципов. Ценный начальный им-
пульс был потерян.
Вывод. Нужно всегда привлекать отдел кадров до начала внедрения процесса, чтобы
обеспечить учет всех человеческих факторов.
Шаг 3. Определение типов деятельности
Сначала посмотрим, из чего состоит «деятельность». Это может быть процесс целиком
или части (операции) процесса. В любом случае, деятельность должна вносить вклад и при-
носить пользу, решая задачи процесса, определенные и оформленные ранее. Деятельность
(комплекс операций) должна быть четко сформулирована и доведена до сотрудников, ис-
полняющих операции. В результате исполнители проекта будут уверены, что прекрасно по-
нимают, что именно от них требуется, насколько грамотное исполнение операций ожидает-
ся, и для чего необходимо решение задач, поставленных перед ними (см. шаг 5).
Модели процессов, созданные на этапе инноваций, покажут операции, связанные с каж-
дым процессом, поэтому анализ этих процессов — важнейший шаг в формулировании опре-
делений деятельности.
Суть этого шага — объединение операций процесса в соответствующую деятельность,
как показано на рис. 18.3.

Шаг 4. Формирование ролей (должностных обязанностей и функций)

Убедившись, что объединение операций в группы (деятельность) произведено правиль-
но, можно начинать сбор типов деятельности в обобщенные «роли» (род занятий). Мы ис-
пользуем термин «роль», а не «должность», потому что на данной стадии это объединение
довольно общее, а термин «должность» подразумевает конкретную функцию лица.
На данном шаге «роль» определяется на более высоком уровне, чем просто должност-
ные обязанности отдельного лица или должностная инструкция. Это обобщенная функция,
как получение квитанций или оценка исковых сумм. (Замечание: мы осознаем, что некото-
рая «должность» может включать несколько ролей в зависимости от размера организации
или подразделения, но в рассматриваемом примере предполагается, что это не так).
Группировка различных типов деятельности в роли может быть итерационным процес-
сом, включающим обсуждение с руководством и непосредственными исполнителями, а за-
тем перегруппировку деятельностей, пока вы и все заинтересованные стороны не будут удо-
влетворены итогами формирования новых ролей.
По окончании данного процесса можно приступать к формулированию новых ролевых
инструкций. В большинстве крупных организаций имеются типовые шаблоны («рыбы») для
ролевых инструкций, так что мы не приводим здесь примеров. Упомянем все же в этой связи
пару соображений, конкретно относящихся к процессам.
Достойны внимания некоторые ключевые составляющие, которые должны быть учтены
при формулировании деятельностей и ролей. Хорошо известная модель RACI (RASCI или
RASIC) полезна при определении деятельности, ролей и обязанностей на этапе работы с пер-
соналом проекта (см. www.valuebasedmanagement.net/methods_raci.html, по состоянию на
июль 2005 года). Эта модель позволяет четко описать, кто и что должен делать, чтобы новый
процесс мог исполняться людьми.
RACI/RASCI — это сокращение:
 R = обязанность — лицо — «хозяин» вопроса или деятельности;
 A = тот, кому лицо «R» подотчетно — тот, кто должен утвердить (принять) работу,
чтобы она формально считалась сделанной;
 S = поддержка / обеспечение — может выделять ресурсы или предоставлять необхо-
димую информацию при выполнении процесса или осуществлении деятельности;
 C = с кем нужно советоваться — тот, кто владеет информацией и/или возможностя-
ми, необходимыми для выполнения процесса или осуществления деятельности;
 I = кто должен быть информирован — тот, кого нужно поставить в известность о ре-
зультатах процесса или деятельности, но с кем не нужно советоваться во время исполнения.
Эти ключевые составляющие (в виде сокращений) можно изобразить на схеме конкрет-
ной обобщенной роли. В табл. 18.1 приводится пример взаимодействия пяти ролей с обоб-
щенной ролью.
Таблица. 18.1 Типовая модель RASCI
деятель- менеджер мене- руководитель руководи- советник по со-
ность бизнес- джер бизнес- тель группы блюдению зако-
подразделе- подразделе- нодательства
ния ния
1. R A
2. A R S C
3. RA I I
4. RA C
5. A R S

Последовательность заполнения этой таблицы такова:

1. Выделить все типы деятельности, определенные на шаге 3, и нанести их на верти-
кальную ось.
2. Выделить все вероятные роли в будущем, нанести их на горизонтальной оси и запол-
нить ячейки таблицы буквами R, A, S, C, I для каждого типа деятельности.
3. Разобраться с разрывами и наложениями. Могут быть ситуации, при которых для ка-
кой-либо деятельности нет ни одного «R», есть несколько «R», либо нет «A». Общее правило
таково: каждая деятельность должна иметь только одно «R» и, по крайней мере, одно «A».
Здесь требуется разрешение конфликта или правил заполнения.
При рассмотрении обобщенных ролей у руководства организации появляется редкая
возможность не только наделить персонал полномочиями и сделать его работу более инте-
ресной, но и вознаграждать сотрудников более замысловато (и не только финансово), а так-
же открыть горизонты для повышения по служебной лестнице. Чем в большей степени это
учтено, тем легче будет убедить людей принять перемены и, следовательно, реализовать их.
Большинство ролевых инструкций должны включать уровень полномочий, политику и
процедуры, распределение обязанностей и соображения окружающей обстановки. Однако
связанная с процессами ролевая инструкция должна также содержать показатели производи-
тельности для каждой части сквозного процесса или подпроцесса, что и приводит нас к шагу
5.
Шаг 5. Измерение и управление производительностью
При работе с процессами часто цитируется фраза: «Что измеришь, то и получишь». Без
измерения нет управления, но если измерять хотя бы критические участки процесса и ис-
пользовать эту информацию разумно, то результаты не заставят себя долго ждать.
Управление производительностью охватывает как эффективность отдельных процессов,
так и производительность людей. В данной главе рассматриваются только аспекты, связан-
ные с людьми, а эффективности самих процессов посвящена глава этапа устойчивого функ-
ционирования.
Луис Герстнер (Louis Gerstner, [19]) говорил, что «поскольку делается не то, что вы
предполагаете, а то, что вы проверяете, нужно найти способ измерения результатов».
Перед тем как начать управление производительностью сотрудников и ее измерение,
нужно иметь четкое представление о человеческом потенциале бизнес-подразделения или
организации. Подразделение переукомплектовано, недоукомлектовано, или же количество
сотрудников как раз на нужном уровне?
Смысл работы с моделями распределения персонала в этом контексте — обеспечить ре-
алистичность нормативов производительности, установленных руководством, и не превы-
шать уровня, на который способен имеющийся штат работников. Распределение персонала
осуществляется на этапе инноваций, и на его итоги нужно ориентироваться.
Создание системы управления производительностью и системы мер эффективности по
всей организации — критически важный шаг. Если его выполнить неверно, BPM не будет
столь эффективно, как могло бы быть. В литературе о BPM утверждается, что показатели
производительности всех сотрудников (исполнительного руководства, руководителей высо-
кого ранга, менеджеров и исполнителей процессов) должны быть увязаны со стратегией ор-
ганизации, целевыми показателями и задачами процессов. Если такие связи непрочны, то
итоги и производительность становятся разрозненными.
На практике мы обнаружили, что только примерно на первых трех уровнях руководства
должна быть прямая завязка основных показателей производительности на стратегию орга-
низации (таблицы сбалансированных показателей). Распространение таких таблиц на всю
организацию каскадом не срабатывает. Работникам на нижних уровнях организации нужны
простые нормативы, например количество изделий, произведенных за день. Конечно, подоб-
ные показатели можно сформировать так, чтобы они способствовали стратегии и целям ор-
ганизации.
На рис. 18.4 показано, что измерение производительности не может дожидаться этого
этапа, его нужно начинать с самого начала проекта и рассматривать на каждом этапе следу-
ющим образом:
  этапы стратегии организации и архитектуры процессов — получите четкое пред-
ставление требуемых заинтересованными сторонами итоговых результатов и их целей. Этим
целям и результатам должна отвечать и содействовать текущая производительность людей и
процессов. Если стратегия организации увязана с показателями производительности от-
дельного лица, премиями за превышение нормативов и возможностью получить повышение
по службе, то формируется мощная синергия отношений. Этого позволяет добиться подход
с помощью таблиц сбалансированных показателей;
 этап понимания — получите четкое представление о действующих показателях про-
изводительности: насколько они удачны, какие уроки можно извлечь из их применения;
 этап инноваций — завершено планирование структуры штата, что способствует фор-
мированию будущих показателей или нормативов производительности; нормативы форми-
руются по ходу постановки целевых показателей (задач) процессов;
 этап работы с персоналом — вся собранная информация сводится вместе, чтобы увя-
зать ее с нормативами производительности для отдельных работников, групп и руководяще-
го состава;
 этап устойчивого функционирования — система управления производительностью
становится частью повседневной работы, т.е. того, «чем мы все тут занимаемся». Она устой-
чиво поддерживается через постоянную обратную связь и совершенствование.
Наш совет — начать измерение и управление производительностью лишь с небольшого
количества показателей, которые должны быть простыми. При необходимости количество и
сложность управленческих отчетов и показателей может увеличиваться со временем и по
мере накопления опыта. Конечно, такие показатели не должны противоречить задачам дру-
гих процессов и показателям подразделений. На практике же это самая важная и трудная
проблема реализации.
Когда сотрудниками достигнуто понимание новых ролей и связанных с ними типов дея-
тельности, можно устанавливать показатели производительности. Обычно они принимают
форму KRA и KPI [36] (KRA — это основные зоны результатов, KPI — основные показатели
производительности/эффективности).
Измерение производительности ролей бессмысленно, пока организация не обеспечит
понимание сотрудниками причин, по которым установленные показатели важны для органи-
зации.
При определении показателей производительности необходимо обеспечить их соответ-
ствие задачам процессов и стратегии организации, а также содействие им. Разумеется, это
подразумевает и потребности всех заинтересованных в процессах сторон.
Задача руководства — создание климата, в котором люди могут работать эффективно.
Для этого сотрудники должны четко понимать свою роль и соглашаться с нею, а также со
способом измерения их производительности в этой роли. У исполнителей должна иметься
письменная ролевая инструкция, четко прописанные уровни производительности и механизм
обратной связи. Обеспечение данными материалами входит в обязанности руководства.
Нам часто приходилось бывать в организациях, где у сотрудников не было четкого по-
нимания своих должностных ролей, целей и методов оценки. Если вы не знаете правил, как
можно рассчитывать на удачную игру, не говоря уже о выигрыше?! Этот шаг кажется та-
ким элементарным и фундаментальным, и все же организации продолжают осуществлять его
плохо, что часто может становиться крупной частью проблем процессов.
Более того, в функции руководства также входит прислушиваться к исполнителям про-
цессов, специалистам и владеющим глубокими познаниями людям, которые могут дать от-
личные предложения по совершенствованию процессов. Руководители должны зажечь ис-
кру, вдохновляющую людей на идеи, лежащие вне узких рамок их работы. Руководители
должны сами постоянно отслеживать процессы или обеспечивать механизмы для этого
(внутренние и внешние). Более подробно данные функции рассматриваются на этапе устой-
чивого функционирования.
Здесь полезно приостановиться и взглянуть на все со стороны, определить перспективу.
Хотя при создании «процессного предприятия» рекомендуется советоваться с исполнителя-
ми процессов и включать их в орбиту обсуждений, все же это не демократия. Руководство
принимает решения, «как здесь делается дело», а люди исполняют эти решения. Руководите-
лю вполне уместно сказать «нет» исполнителям процессов, просто до них нужно донести
причину этого «нет», что обеспечит более глубокий взгляд на цели организации. Раз уж ру-
ководство приняло решение, исполнители не могут однажды утром решить реализовывать
процессы иным образом. В конечном итоге это приведет к хаосу в процессах и операцион-
ной работе или к неэффективности и непродуктивности процессов.
После определения всех запросов абсолютно необходимо, чтобы руководство правильно
применяло управление производительностью и адекватно оценивало сведения о производи-
тельности. Никогда нельзя использовать их в целях наказания, но всегда — в качестве сред-
ства обучения и повышения производительности, улучшения способности руководства и
людей принимать решения.
В идеале не менеджеры должны сообщать исполнителям сведения об измерениях произ-
водительности. Эти данные должны приходить к сотрудникам напрямую или быть доступ-
ными для них. Тогда у людей будет возможность инициативно исправить любую ситуацию
еще до того, как она станет головной болью руководства или бизнес-подразделения.
Людей никогда не должна удивлять информация о показателях производительности,
исходящая от руководства.
Эта информация должна быть доступна всем людям в бизнес-подразделении или группе
процесса. Важный прием управления — внесение толики конкуренции, добиться которого
легко, просто обнародовав задачи группы и индивидуальные показатели производительности
всех членов группы.
Самый последний вопрос, который должно задать себе руководство, — соответствуют
ли отдельные работники порученным им делам? Не стоит торопиться с выводами о способ-
ностях сотрудников, пока не изучена вся предшествующая картина.
Пример управления производительностью. Вот небольшой пример того, как могло бы
работать управление производительностью внутри организации. Он основан на реальной си-
туации в одном учреждении по оказанию финансовых услуг.
Организация выполнила анализ процессов, квалификационных требований к исполните-
лям и провела планирование штата бизнес-подразделения.
Было решено сформировать новые роли (не расширяя штат), чтобы больше нацелиться
на желаемые показатели. Были созданы две новые роли - специалист по:
 взаимоотношениям
 администрированию.
Ранее обе роли выполнялись одним должностным лицом.
Были изучены типы деятельности в процессах и написаны должностные инструкции, от-
ражающие выполняемые процессы и желаемые результаты.
Новые предложенные нормативы по-прежнему основывались на подходе с помощью
таблиц сбалансированных показателей, который уже был внедрен в организации.
Нормативы на более низких уровнях должны были способствовать выполнению норма-
тивов на более высоком уровне и совокупно — на верхних уровнях (например, нормативы
административного персонала «вкладывались» в нормативы глав групп, нормативы глав
групп способствовали выполнению нормативов менеджеров и т.д.).
Пример такого подхода иллюстрируется на рис. 18.5.
 Планирование штата подсказало руководству и персоналу, что установленные для раз-
личных ролей нормативы реалистичны и достижимы, поскольку подразделение не было ни
пере-, ни недоукомплектовано. Нормативы производительности должны были отражать объ-
ем и качество работы; каждый из них рассматривается ниже.
На рис. 18.6 показана предложенная структура и подход к администрированию, а также
связанные с ней нормативы производительности. Эта схема была проанализирована на
предмет увязки со стратегией организации, и ее целями, а также задачами и целями отделов.
Нормативы для администрирования включали как индивидуальные показатели, так и норма-
тивы группы. Индивидуальные нормативы, например, представляли собой количество еди-
ниц работы (или единиц труда), выполненных за определенный период времени. Единица
работы была установлена для 15 мин. Применение единиц работы вместо количества тран-
закций, обработанных за интервал времени, объяснялось тем, что это давало возможность
преодолеть разницу во времени обработки различных типов транзакций, например обработ-
ка некоторых из них требовала до 15 мин, а других — несколько часов.

Применение единиц работы требовало изучения каждого типа транзакций, чтобы опре-
делить количество единиц работы или усилий на его обработку. Большинство этих сведений
было получено в ходе работы по проекту на этапах понимания и инноваций. Например, про-
цесс А требовал 1,25 единиц работы, а транзакция типа B — 2,5 единицы. Единицы работы
всех процессов округлялись до ближайших 0,25 единиц. Исходя из стандартного рабочего
дня — 6,25 ч — это давало выработку 25 единиц работы в день на человека. (Персонал рабо-
тал с 8.30 до 17.00 ежедневно, что составляло 8,5 ч с часовым перерывом на обед и по 0,25 ч
на утренний и послеобеденный перерывы, походы в туалет и прочее, организация приняла
эффективную продолжительность рабочего дня 6,25 ч).
На более детальном уровне в рассматриваемой организации для администрирования и
главы группы были установлены следующие нормативы:
 количество единиц работы в неделю должно было равняться 135, т.е. по 25 единиц в
день (6,25 ч, деленные на 15 мин), или 125 в неделю, плюс 10 единиц как стимулирующий
норматив. Если работник участвовал в собраниях группы, проходил обучение и т.п., это вре-
мя учитывалось в единицах работы, и они прибавлялись к общему числу;
 в группу входили 10 человек, и глава группы установил норматив 135 единиц, умно-
женные на 10, или 1350 единиц работы в неделю на группу. Групповой норматив стимули-
ровал работников помогать другим членам группы, которые, возможно, не справлялись из-за
неопытности или избытка работы, а группа должна была выйти на целевой процентный по-
казатель процесса в 90%;
 нормативы качества были также установлены на индивидуальном и групповом уров-
нях. Первоначально работникам давалась «поблажка» в виде разрешения небольшого числа
ошибок обработки в неделю (по мере накопления опыта допускаемое число ошибок стреми-
лось к нулю), но для группы в целом был установлен нулевой «внешний» норматив числа
ошибок, т.е. члены группы должны были проверять друг друга, чтобы до клиента или других
заинтересованных сторон ошибки не доходили.
 Нормативы для глав группы включали:
 те же групповые нормативы, что и для администрирования. Такое положение дел
стимулировало глав групп так, чтобы это было выгодно всем (организации, руководству,
главам и членам групп);
 соблюдение сроков процессов в 90% случаях, что стимулировало глав групп руково-
дить своими коллективами упреждающе, равномерно распределяя нагрузку и предупреждая
накопление невыполненной работы;
 норматив по достижению задач процессов всего отдела, что стимулировало взаимо-
помощь между главами групп одного отдела.
Такое совокупное накопление и формирование нормативов проходило вверх по всей
иерархии до каждого уровня управления.
Чтобы повысить квалификационный уровень в организации, персонал должен был обес-
печить пересылку ошибок обратно работнику, ставшему их первопричиной. Это давало об-
ратную связь показателей с работником. За переделывание работы никакие дополнительные
единицы не начислялись.
Члены групп ежедневно фиксировали свою выработку и могли постоянно видеть показа-
тели производительности других членов и всей группы.
Глава и члены группы могли также наблюдать сведения о числе транзакций в процессе
обработки и при любых отставаниях в работе. Это давало возможность убедиться, что задачи
процесса выполнены. Сведения, необходимые для измерений выработки, включались в от-
чет, показанный на рис. 18.7.

Тип тран- Перенесено Новые Обработанные транзакции Перенесены на сле-

закции из прошедше- транзакции дующий период
го периода (оставшийся срок
для выполнения
SLA, дней)
Требования Нестандартные
соглашения (OOS)
уровня об-
служивания
(SLA) выпол-
нены
Рис. 18.7 Простые показатели выработки и обслуживания. Воспроизведено с разрешения
MPM Group Ltd, работающей под торговой маркой TouchPoint Process Management Services
Эти сведения были доступны по каждому работнику, группе, отделу и подразделению за
любой период.
Для каждого типа транзакций предоставлялись следующие сведения:
1. Число транзакций, перешедших с предыдущего периода.
2. Число транзакций, полученных в новом периоде (новые трансакции).
3. Число обработанных за период транзакций, которые:
o отвечали параметрам соответствующих соглашений об уровне обслуживания
(SLA);
o были нестандартными (OOS).
4. Число транзакций, перенесенных на следующий период, включая количество дней,
оставшихся по параметрам SLA, или уже с нарушением стандарта.
Нужно всегда помнить, что нормативы производительности приносят пользу, только
если они регистрируются, обеспечивается обратная связь со всеми исполнителями, а итоги
оцениваются и вознаграждаются.
Шаг 6. Анализ пробелов ключевых способностей персонала
На этом шаге проект обращается к способностям и квалификации людей. Заполнение
матрицы способностей началось ранее, на этапе понимания, и теперь ее надо обновить и
окончательно сформировать. Как заполнять эту матрицу, рассказано в главе 16, но мы по-
вторим это здесь. Матрица должна оказать помощь группе проекта и бизнес-подразделению
в составлении анализа разрыва между квалификацией персонала на данный момент, требуе-
мой действующими процессами и потребностями будущих процессов, а также вытекающих
из них типов деятельности и ролей. Очевидно, что на этом шаге, как и на всем данном этапе,
должен активно привлекаться отдел кадров.
Хотя эта матрица показывает способности, необходимые для новых ролей, аналогичную
матрицу нужно составить для способностей, имеющихся у исполнителей процессов в насто-
ящий момент.
Если избран путь обучения или подготовки в процессе работы уже имеющегося персо-
нала, нельзя недооценивать время, которое может потребоваться для изменения привычек и
поведения. Этому следует посвятить значительные усилия, время и ресурсы.
Кейс: поддержка менеджера отдела кадров
Мы взялись за новый проект фундаментального пересмотра существующих процессов в
некой организации и провели собеседования с заинтересованными сторонами, чтобы выяс-
нить их личные мотивы. Менеджер по персоналу сказал, что его личный мотив — более тес-
но работать с бизнес-подразделениями в вопросах кадров. Ему хотелось большей ориента-
ции на потребности бизнеса, а не постоянного проталкивания своих идей.
На этапе инноваций мы поработали с различными заинтересованными лицами и смогли
обеспечить увязку новых процессов с требуемой квалификацией персонала. Эти профессио-
нально-квалификационные навыки соответствовали функциональным и должностным обя-
занностям и программам обучения, а также измерениям производительности. Такой подход
не только обеспечил учет проблем, стоявших перед менеджером отдела кадров, но и просто-
ту обращения работников к квалификационным требованиям (включая обучающие модули)
для выполнения других функций.
Вывод. Чрезвычайно важно объединить все аспекты (ролевые инструкции, обучение,
измерение производительности, процессы и предполагаемые итоги/результаты), поэтому от-
дел кадров и бизнес-подразделение должны тесно сотрудничать.
Шаг 7. Разработка структуры организации
Этот шаг нужен для перестройки структуры организации, и первое, что нужно сделать,
— посмотреть на организацию в перспективе. Структуры обычно создаются одним из не-
скольких способов, и их можно снова увязать с выбранным сценарием реализации BPM. Че-
тыре возможных сценария реализации BPM были названы так:
 обычная работа;
 рулевой;
 пилотный проект;
 вне поля зрения.
Только первый и второй сценарии, вероятно, сразу окажут какое-либо влияние на струк-
туру организации, остальные два, скорее всего, будут со временем воздействовать на более
широкую структуру.
На рис. 18.8 показано, как можно создавать структуру организации.

На этом рисунке видно, что обычно структура организации формируется из двух частей.
Руководитель организации определяет верхние ярусы организационной схемы — своих
непосредственных подчиненных и сферы их ответственности, которые могут далее делиться
по продуктам, клиентам, каналам дистрибуции и т.п. Прямые подчиненные определяют сле-
дующий ярус и т.д. Такое формирование структуры определяется службами и «вертикалями
подчиненности» и может быть связано либо не связано с процессами организации. Этот спо-
соб называют «сверху вниз».
 Нижняя половина организационной структуры может формироваться либо «снизу
вверх» (на основе подхода с процессами в сердцевине) или «от середины вниз» (согласно
определяющим структуру решениям руководителя организации и его непосредственных
подчиненных, обычно по функциональным характеристикам). Подход «от середины вниз»
— это традиционно принятый способ формирования структуры организации, тогда как при
процессно-центрированном подходе предпочтение отдается способу «снизу вверх». В по-
следнем случае важно начать с разбиения процессов на типы деятельности (как описано на
шаге 3 и далее). И тогда нужно будет различать опорные и вспомогательные (поддерж-
ки/обеспечения) процессы организации, а также «стратегические» процессы и процессы
«управления», при этом роли и структура должны отражать это разбиение.
Функционально выстроенная структура организации порождает напряженность между
различными отделами организации или бизнес-подразделениями, поскольку процессы
сквозные и пересекают границы структурных подразделений. Чтобы способствовать снятию
этой напряженности, многие организации прибегают к матричной структурной схеме, когда
функциональные менеджеры отвечают за обычные сферы продаж, производства, маркетинга
и т.п., а менеджеры процессов — за цепочку ценности или обобщенные сквозные процессы.
В этой ситуации необходим посреднический коммуникативный процесс, позволяющий раз-
решать конфликты.
У менеджеров процессов обычно существует иерархия, распределяющая обязанности от
обобщенных процессов и цепочек создания ценности до подпроцессов. Роль главного руко-
водителя процессов заключается в координации всех менеджеров процессов. Если создана
матричная структурная схема, важно привязать к такой структуре системы премирования и
вознаграждений.
Во всех случаях задача организационной структуры состоит в том, чтобы:
 предлагаемая новая структура предназначалась для поддержки стратегии организации
и показателей процессов;
 свести к минимуму разрывы процессов между подразделениями — их невозможно
уничтожить, но можно многого достичь на пути их минимизации. В структуре по-
настоящему процессно-центрированной организации с перестройкой сквозных процессов
разрывы в процессах должны исчезнуть или почти исчезнуть.
Достичь этого можно, если подойти к созданию структуры организации как к процессу.
Сформируйте общую (грубую) модель, а затем постепенно моделируйте перестроенную
схему организации более подробно. Создайте новую модель организационных взаимосвязей,
чтобы свести, насколько возможно, к минимуму разрывы процессов.
Организационно-структурная схема должна:
 минимизировать «стыки» между отделами;
 добиваться максимальной результативности и эффективности процессов;
 минимизировать количество ярусов управления;
 обеспечить максимальную ясность и четкость.
Важно не увлечься достижением полного совершенства структуры, хотя нужно сделать
все возможное для формирования правильной структуры с учетом всех девяти компонентов
в описанной ранее схеме производительности [29]. Но организационная структура может
иметь огромное значение для функционирования организации, если схема явно неверна, по-
тому что часто вызывает нестыковки (с точки зрения процессов). Важнее отладить нижние
ярусы структуры организации, потому что именно там «делаются дела».
Помните, что структура следует за стратегией и перестройкой процессов. Как часть
процесса определения идеальной структуры организации необходимо рассмотрение новой
«процессной среды», в том числе ее измерения и управление ею. Фактически, методика из-
мерения процессов вполне может дать ответ на вопрос, как должна быть структурирована
организация. В операционной сфере руководство существует для «управления» людьми и
процессами, требуя возможности измерять производительность людей и процессов.
Организациями, структурированными процессно-центрированно, управлять труднее, по-
тому что необходимы более развитые навыки управления. Руководство должно уделять зна-
чительное внимание измерению производительности, мотивации, вознаграждениям и куль-
туре.
Нет одного правильного решения относительно структуры организации — она будет за-
висеть от требований и конкретных обстоятельств; но:
 …существует очевидно неправильное решение. Оно вверяет все полномочия и контроль
менеджерам отделов и создает стимулы для менеджеров в соответствии с показателями
отделов. Это почти всегда приводит к «частичной» оптимизации усовершенствования
процессов и эффективности функционирования корпорации.
Хармон, [32]
В нынешней обстановке все более быстрых перемен для долгосрочного выживания ор-
ганизациям нужно быть гибкими и адаптируемыми. Поэтому структура организации должна
быть подвижной и способной динамично меняться, постоянно подстраиваясь под деловую
среду и требования организации.
Шаг 8. Пересмотр политики в отношении персонала
Окончательно определив описанные выше элементы, необходимо пересмотреть или
сформулировать различные положения и руководства по политике, процедурам, груп-
пам/семействам смежных должностей (ролей), структуре вознаграждений и другую доку-
ментацию отдела кадров. Рассматривая подход к разработке таких положений в различных
сферах, подумайте об использовании инструмента моделирования, чтобы состыковать моде-
ли новых процессов с документацией по политике и процедурам в соответствующих точках.
После этого документацию нужно выложить в сети организации. Среди другой документа-
ции, требующей пересмотра, назовем схему стимулирующих вознаграждений, которые мож-
но напрямую связать с измерениями производительности и удовлетворенности клиентов.
Шаг 9. Планирование обучения (на рисунке – Обучение – С.К.)
На этапе понимания организация начала выявлять потребности в информации и знаниях
и заполнять матрицу способностей, которая на данном этапе была расширена и заполнена на
шаге анализа разрывов базовых способностей. Полученные результаты теперь можно ис-
пользовать для разработки стратегии и плана обучения.
Необходимо обеспечить, и как можно раньше, участие отдела обучения в определении
новых типов деятельности и происходящих изменений ролевых инструкций, а также обеспе-
чить отдел исчерпывающей информацией. Разумеется, в этом деле требуется постоянное
взаимодействие и помощь отдела кадров.
Задача — спланировать и отобразить на бумаге требования к обучению с точки зрения
процессов. Обучение системам, прописанное на этапе разработки, дает входную информа-
цию для данного шага.
Разработка программы обучения также предполагает:
 анализ потребностей в обучении;
 анализ приемов обучения (как документировать и осуществлять обучение);
 разработку материалов обучения;
 своевременное направление людей на обучение — бессмысленно обучать людей за-
долго до того, как им потребуются соответствующие знания: они просто забудут все, чему
их учили.
В формулировании требований обучения очень полезен анализ разрыва между действу-
ющими процессами, смоделированными на этапе понимания, и новыми процессами, разра-
ботанными и смоделированными на этапе инноваций (более подробно см. шаг 12 этапа ин-
новаций).
При планировании обучения нужно подумать о следующих моментах:
1. Как будет проводиться обучение:
 преподавателями-профессионалами;
 искусными супер-пользователями из бизнес-подразделений (их преимущество в том,
что они досконально знают бизнес и процессы; это позволит продолжить обучение внутрен-
ними «учителями» на этапе реализации);
 «пилотными» сеансами обучения, что дает возможность получить обратную связь и
«обучить учителей».
Обучение должно учитывать «разрывы», найденные при анализе матрицы ключевых
способностей персонала.
2. Кого нужно привлечь к разработке плана обучения:
 группу проекта;
 отделы кадров и обучения;
 представителей исполнительных групп;
 руководство.
 3. Какой формат нужно использовать:
 семинары;
 самообучение;
 обучение в процессе работы;
 самообучение по учебникам.
Сделайте так, чтобы первоначальное обучение и материалы содержали формы для об-
ратной связи, которые можно использовать для совершенствования методики обучения по
мере ее распространения по организации. Преподаватели и учителя также должны обеспечи-
вать обратную связь.
Реализация ценности. На данном этапе необходимо до мелочей определить выигрыши,
чтобы добиться согласия. Подробности описаны в главе 21 (шаг 5) в связи с реализацией
ценности в проекте.
Результаты этапа работы с персоналом. Этап работы с персоналом вносит значимый
вклад в другие этапы (рис. 18.9). Вот лишь несколько примеров:

 проработка измерений производительности может показать, что нужны изменения в

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

1. Недостаточен контакт и Контакты и связи — функция менеджера проекта,

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

2. Оценка производитель- До того как оценивать персонал по его производи-

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

3. Не полностью выполнено Внесите планирование структуры персонала в план

планирование структуры персо- проекта и убедите заинтересованные стороны в важ-
нала ности этого мероприятия

4. Нормативы для персона- Эти данные должно дать планирование персонала

ла нереальны, потому что биз-
нес-подразделение недоуком-
плектовано

5. При определении показа- Управление изменениями персонала — важнейшая

телей производительности не часть любого проекта. Если людей не взяли в эту до-
посоветовались с исполнителя- рогу, они могут отказаться принять изменения и ис-
ми и не привлекли их пользовать их

6. Отдел кадров был слиш- Если не привлечь отдел кадров, это может повлечь
ком поздно привлечен в проект существенные задержки, негативный эффект и пере-
или не был привлечен вовсе делки. Привлечение данного отдела следует считать
задачей плана проекта на самой ранней стадии.
Нужно назначить ответственного за это, а менеджер
проекта должен обеспечить решение этой задачи.
Информируйте отдел кадров о сроках проекта

Глава 19. Этап разработки. Назначение

Мы уже подчеркивали, что для успеха проекта BPM автоматизация необязательна, и в
главе 3 утверждалось, что важно отладить бизнес-процессы, перед тем как автоматизировать
их. Поэтому этап разработки (рис. 19.1) содержит шаги, необходимые для перевода вновь
перестроенных или усовершенствованных процессов с этапа инноваций на этап реализации
и внедрения. Мы не станем подробно описывать стандартные шаги разработки, поскольку
большинство их в целом очевидно группе проекта. Мы сосредоточимся на разработке авто-
матизированного решения BPM (которое выбиралось на предыдущих этапах) и конкретных
вопросах, отличающих его от «стандартного» решения автоматизации.

На данном этапе завершаются необходимые приготовления, после чего формируется

решение. Затем следует этап реализации — внедрение решения. Нужно понимать, что «раз-
работка» в данном контексте выполняется параллельно с этапом работы с персоналом, где
решаются проблемы «человеческого фактора».
При разработке новой системы нужно проявлять осмотрительность: она должна обеспе-
чивать достаточную гибкость, чтобы отвечать на нужды бизнеса в ближайшем будущем, а
также на частые изменения в бизнес-процессах. Более того, важно осознавать, что во время
разработки системы BPM на этом этапе бизнес-процессы тоже могут измениться. Применя-
емая методика разработки должна предусматривать подобную ситуацию. В противном слу-
чае разработанная система устареет еще при внедрении и серьезно повредит маневренности
организации, и ее бизнес-процессам.
Кейс: дьявол скрывается в деталях
Отдел маркетинга одной организации связи ввел новую схему стимулирования для по-
лучения бонусов, но забыл сообщить об этом в отдел систем. В результате менеджер отдела
систем, прочитав в газете рекламу бонусов, осознал, что от его отдела требуется доработать
системы, чтобы выполнить рекламные обещания. На срочном совещании было решено, что
необходимые изменения будут реализованы за 24 часа. Отдел маркетинга заявил: «Нас не
интересует, сколько это стоит, внесите изменения, дающие нам возможность выполнить
обещанное в рекламе». Программист за день внес изменения в систему, и все, казалось, ра-
ботало прекрасно. Но из-за вариантов, которые пришлось выбрать для осуществления быст-
рой доработки на ходу, более половины всех будущих маркетинговых действий система не
могла поддержать — явный случай «частичной» организационной (суб)оптимизации.
Вывод. Перед внесением изменений в систему подумайте о них и их воздействии и за-
ручитесь участием всех заинтересованных сторон.
Концепция автоматизации BPM состоит в том, что технология BPM позволяет выделить
бизнес-правила и компоненты бизнес-процессов приложения в свои собственные «слои».
Смит и Фингар в книге о третьей волне BPM (Smith, Fingar) [68] считают, что система охва-
тывает три широкие области, как показано на рис. 19.2:

1. Интеграция внешних систем (компонент EAI).

2. Автоматизация того, что они называют процессами (бизнес-правила и библиотеки
процессов).
3. Сотрудничество с внешними контрагентами — клиентами, бизнес-партнерами, кана-
лами дистрибуции, узлами-накопителями и биржами бизнес-информации.
Хотя отдельные компоненты технологий уже существуют какое-то время, именно инте-
грация компонентов и нарастающее процессно-центрированное мышление дают качествен-
ный скачок.
Если бы мы смогли заглянуть в будущее, то довольно спорным оказалось бы мнение, что
у старых систем приложений, которые хорошо служили крупным организациям, хотя и
накладывали на них существенные ограничения, будет потенциал оставаться «только»:
 крупными хранилищами данных и библиотеками управления;
 крупными модулями обработки пакетных заданий массовой обработки, которая тре-
буется большим организациям (например, обработка продлений полисов в страховой компа-
нии);
 драйверами отчетности и распечатки для массовых или объемных заданий (опять же
пример распечатки продлений полисов в страховой компании, если такие работы не отданы
в аутсорсинг, или крупных объемов отчетов).
Недавние изменения в технологии означают, что сейчас легче и проще разработать и
внедрить автоматизированное решение BPM, чем в прошлом (в предположении правильно-
сти подхода). Более того, сегодняшние технологии позволяют бизнесу плотнее участвовать в
разработке и управлении таких систем. Другими словами, бизнес может двигать автоматиза-
цию системы BPM.
Результаты этого этапа таковы:
1. общее описание решения.
2. Подробные бизнес-требования.
3. Окончательная доработка документации по выбору ПО.
4. Спецификации/технические условия на ПО.
5. Разработка/конфигурирование ПО.
6. Программы тестирования ПО и результаты.
7. Спецификации аппаратного обеспечения.
8. Наличие аппаратуры
9. Программа испытаний аппаратуры и результаты.
10. Программа испытаний интеграции и результаты.
Осуществление. Существует два способа разработать автоматизированное решение
BPM:
 традиционный подход по методу цикла разработки ПО (SDLC) (спецификация,
разработка, тестирование) и
 итеративный метод быстрой разработки приложений(RAD).
Эта глава отличается от других, поскольку дает лишь общее описание нескольких круп-
ных шагов (рис. 19.3), которые необходимо принять во внимание при реализации автомати-
зированного решения BPM. Подробные пошаговые методики SDLC и RAD достаточно пол-
но освещены в других публикациях и предметом этой книги не являются.

Шаг 1. Обмен информацией

На этапе разработки важно довести объем и предполагаемую степень автоматизации до
всех заинтересованных сторон. Важно также решить основные вопросы, которые возникают
в случае автоматизации:
1. Cохраню ли я свою работу?
2. Какие новые навыки мне потребуются?
3. Как изменится моя работа?
Автоматизация, возможно, также окажет влияние на взаимодействие с партнерами, по-
ставщиками и клиентами. Веб-сервисы и сервисно-ориентированная архитектура значитель-
но упростили интеграцию процессов через границы организации. Если это именно такой
случай, то донесение информации следует также распространить и на третьи стороны, указав
не только выгоды и воздействие автоматизации, но и развитие, проблемы и потенциальные
задержки.
Шаг 2. Определение компонент BPM
Одно из первых решений, которые нужно принять на этапе разработки, — какие компо-
ненты автоматизированного BPM требуются — речь идет о принятии решения по необходи-
мым инструментам. Вполне может оказаться, что на данной стадии решение окончательно
утверждается, а не принимается. Некоторые инструменты уже могли быть приобретены для
предшествующих этапов проекта (например, инструмент моделирования процессов и ком-
поненты управления), а другие были рассмотрены на этапе инноваций (например, модуль-
машина бизнес-правил или процессов).
 Автоматизированное решение может состоять из одного или нескольких следующих
компонентов:
1. модуль (машина) рабочих потоков.
2. Модуль бизнес-правил.
3. Интеграция (интеграция приложений предприятия — EAI).
4. Интегрированная система управления документами.
5. Мониторинг бизнес-деятельности (BAM).
Остальные компоненты автоматизированного решения — инструмент моделирования и
управления процессами, имитационное моделирование, учет затрат по типам деятельности и
сбалансированной системы показателей. Эти компоненты больше ориентированы на моде-
лирование и конфигурирование процессов, и в данной главе не рассматриваются. На рис.
19.4 показаны все компоненты.
При автоматизации процессов главный вызов, стоящий перед проектом, заключается в
получении данных, требующихся для этого процесса. Такие данные могут быть разбросаны
по нескольким старым системам. Исходя из доступности данных, проект должен определить,
какие компоненты автоматизированного BPM предполагается применять для разработки ре-
шения.

Шаг 3. Решение повторно использовать, приобрести, создать или отдать в аутсор-

синг
Следующее решение в проекте относится к подходу, который будет принят в отношении
источника различных компонент ПО:
1. сделать / повторно использовать имеющуюся систему.
Основные достоинства:
 синергия и экономия на объемах;
 система известна и уже зарекомендовала себя.
Основной недостаток или проблема:
 система не отвечает всем сегодняшним требованиям или не обеспечивает достаточ-
ной гибкости для вероятных новых требований.
2. Купить готовый к применению стандартный продукт, который можно сконфигуриро-
вать.
Многие поставщики решений BPM сегодня предлагают «каркас» приложений, которые
предназначены стать опорными стартовыми точками для организаций. От них не ожидается
полного решения, но они обеспечивают простую конструкцию, которую организация может
расширять (конфигурировать) под свои конкретные требования. Если такое «рамочное» ре-
шение существует и в целом удовлетворяет требованиям бизнеса, это может дать суще-
ственные преимущества организации (и проекту).
Примеры подобных «каркасных» решений: обработка страховых требований возмеще-
ния ущерба, различные приложения связи и обработка заявок на кредиты.
Основные достоинства:
 вероятность получить пригодный продукт или стартовый пункт;
 решение, которое отвечает конкретной ситуации в организации и на рынке;
 обеспечена поддержка продукта.
Основные недостатки или проблемы:
 дополнительные расходы (хотя, в конце концов, может оказаться экономией средств);
  важно, чтобы начальная «каркасная» конфигурация отвечала требованиям организа-
ции, в противном случае она моментально устаревает (конфигурирование похоже на укладку
бетона в арматуру: сначала он текучий, но потом застывает в камень);
 разработка системы по несформировавшимся требованиям, что может ограничить
гибкость в будущем.
Разработка новой специализированной системы. Если это вообще возможно, то, как
правило, подобного развития событий нужно избежать.
Основное достоинство:
 систему можно целиком настроить и сконфигурировать для данной организации.
Основные недостатки или проблемы:
 значительные расходы и время разработки, а также текущие эксплуатационные затра-
ты;
 риски проекта включают задержку сроков сдачи, низкое качество и повышенные рас-
ходы.
Аутсорсинг приложений
Этот вариант приобретает все более широкое распространение и должен быть серьезно
изучен.
Основные достоинства:
 используются существующие знания и процессы разработчика;
 синергия и экономия на объемах.
Основные недостатки или проблемы:
 расходы по передаче стороннему подрядчику;
 недостаточная гибкость.
(См. Приложение L - стр. 275, где более подробно рассматривается аутсорсинг бизнес-
процессов – не увидела там такого – С.К.).
Количество систем
Автоматизированное решение почти наверняка будет содержать не один компонент,
например модуль-систему рабочих потоков, автоматизированный модуль бизнес-правил и
систему управления документами. В ситуации с несколькими автоматизированными компо-
нентами следует обратить внимание на тот факт, что с ростом количества систем существен-
но растет число интерфейсов, как и объем усилий, необходимых для разработки и поддерж-
ки этих интерфейсов.
Шаг 4. Обновление функционально-технических спецификаций
Должен быть структурированный подход к спецификациям (функциональным, техниче-
ским и системным или проектировочным), разработке и тестированию решения BPM, как
это изображено на рис. 19.5. V-схема показывает «недостающие звенья» между самими спе-
цификациями и техническими условиями и тестированием. В недостающих звеньях, пред-
ставленных на этом рисунке, зачастую скрываются коренные причины провалов многих
проектов разработки систем в прошлом.
 В левой части рисунка показаны бизнес-требования и соответствующая документация
по разработке, а в правой части — тестирование, которое должно подтвердить соответствие
продукта группы разработчиков этим требованиям и документам разработки. Проблема за-
ключается в обеспечении соответствия ожиданиям с точки зрения бизнеса, и именно бизнес
определяет, удалось ли этого достичь. Прямоугольники над пунктирной линией относятся к
функциональным возможностям, а ниже этой линии — к техническим аспектам.
Общая проблема на этапе разработки — конфликт между желаниями бизнеса и тем, как
разработчики интерпретируют требования. Часто это зависит от взаимодействия и совмест-
ной работы двух заинтересованных сторон и понимания того, что подразумевают такие от-
ношения.
Сколько раз приходилось слышать о ситуациях, когда бизнес вырабатывает специфика-
ционные требования, технический персонал перерабатывает их в технические функциональ-
ные спецификации на языке, малопонятном бизнесу, и чтобы уложиться в сроки, дает биз-
нес-подразделению три дня на утверждение. Бизнес-подразделению не просто трудно понять
технический язык, ему нужно одновременно вести обычную деятельность, поэтому уло-
житься в трехдневный срок практически невозможно. Чтобы избежать задержек, бизнес-
подразделение утверждает функциональные спецификации, не отдавая себе отчет о послед-
ствиях. Группа разработчиков теперь создает новую систему BPM и сдает ее бизнес-
подразделению. На стадии тестирования заинтересованные стороны заявляют, что система
не отвечает их ожиданиям, утверждая, что «это не то, что они хотели!» Ответ группы разра-
ботчиков: «Это не так. См. с. 179 утвержденных технических условий разработки». Бизнес-
подразделение отвечает: «Но это совсем не то, что мы имели в виду», после чего проект пе-
реходит на стадию переделывания, а это, в свою очередь, ведет к затягиванию сроков, уве-
личению затрат и упущенным потенциальным бизнес-возможностям.
Так выглядит традиционный подход цикла разработки SDLC, и при этом создается ситу-
ация повышенного риска проекта BPM.
Риски можно минимизировать несколькими способами:
1. проведите анализ «что если…».
2. Проведите имитационное моделирование.
3. Определите, что не входит в объем проекта.
4. Бизнес-требования разрабатываются на этапе инноваций, а функциональная схема —
на этапе разработки. Однако чрезвычайно важно обеспечить тесное сотрудничество бизнеса
с техническим персоналом и совместно составить функциональную схему. У бизнес-
подразделения должна быть возможность утвердить документ, полностью осознавая послед-
ствия и обеспечив соответствие и содействие требований бизнес-стратегии и целям. Хоро-
ший способ добиться понимания бизнес-требований — составить их, исходя из процессной
точки зрения. Разделите функциональную схему и техническую разработку.
5. Определите последствия разработки и добейтесь согласия по ним.
1. Как указано в главе 14, важно применять архитектуру гибко. Например, что делать,
если появилось срочное бизнес-требование, а решение не укладывается в архитектуру? Один
из вариантов — дать возможность проработать требование и установить строгие правила ра-
боты с таким исключением (например, решение должно быть выведено из эксплуатации в
течение Х месяцев или соответствовать архитектуре в течение N месяцев). Такой механизм
«клапана скороварки» очень важен, поэтому окончательный тест архитектуры — способ об-
работки исключений. Отвергать или игнорировать все исключения может показаться выиг-
рышным подходом, однако это ведет к конечному проигрышу, поскольку люди будут все
больше игнорировать архитектуру.
2. Критично включение требований к программному и аппаратному обеспечению, по-
скольку в большинстве случаев между ними есть взаимозависимость.
Кейс: неверный «быстрый путь»
Оператор связи хотел ввести новую систему для поддержки биллинговых процессов и
обслуживания клиентов, и разработал требования только на основе действующей бизнес-
модели: предоставление услуг наземной связи населению. Когда нам показали исходные
спецификации, мы указали, что они полностью лишают систему гибкости. Исходя из обоб-
щенной бизнес-модели, мы предложили оператору пойти по пути создания системы на осно-
ве переменного комплекса бизнес-параметров, а не жесткого программирования функцио-
нальности в системе. Например, вместо обеспечения услуг только населению, следует
предусмотреть и другие типы клиентов: предприятия и дистрибьюторы, и вместо только од-
ной роли организации (провайдер услуг) — допустить различные типы (сетевой оператор и
дистрибьютор). Оператор совет проигнорировал, и после двух крупных перемен в его стра-
тегии система стала безнадежно сдерживать бизнес, причем, в такой степени, что была упу-
щена редкая возможность увеличить долю рынка, и огромные усилия прилагались для со-
хранения рентабельности.
Вывод. Проведите анализ «что если…», чтобы убедиться, что ваши требования выдер-
жат предполагаемые изменения.
В работе с ПО важный вопрос — применение соответствующих стандартов. С появлени-
ем таких технических средств, как XML, веб-сервисы и сервисно-ориентированная архитек-
тура, возможности распространения автоматизации процессов расширяются далеко за пре-
делы данной организации на поставщиков, клиентов и партнеров. При этом повышается эф-
фективность и быстрота.
Сегодня обсуждать стандарты моделирования, компоновки, исполнения и совместимо-
сти все еще весьма сложно. Нет общего консенсуса между поставщиками инструментов от-
носительно цельного комплекса стандартов BPM, хотя на данный момент лидерами являют-
ся BPEL и BPMN. По этой причине мы настоятельно призываем читателя осознать этот факт
и выйти за рамки дискуссии, чтобы понять, действительно ли стандарты играют существен-
ную роль в конкретной ситуации.
В области BPM ведущая роль сегодня принадлежит следующим стандартам6:
 BPEL (язык исполнения бизнес-процессов). Сейчас это главный язык исполнения, ко-
торый компонует бизнес-процессы, используя веб-сервисы, и позволяет интегрировать и
связывать различные приложения BPM;
 BPML (язык моделирования бизнес-процессов). Непосредственно конкурирует с
BPEL как мета-язык моделирования бизнес-процессов;
 BPMN (спецификации обозначений моделирования бизнес-процессов). Стандарт обо-
значений (т.е. комплекс пиктограмм и графических изображений) для моделирования биз-
нес-процессов. Главная цель этого стандарта — применение общих графических средств мо-
делирования в инструментах моделирования бизнес-процессов и приложениях BPM; таким
образом, BPMN является дополняющим для других стандартов BPM;
 Wf-XML (расширенный язык разметки — XML — для рабочего потока). Обеспечива-
ет взаимодействие и совместимость между модулями-машинами BPM, давая возможность
исполнять длительные бизнес-процессы, задействованные на нескольких машинах-модулях;
 XPDL. Язык определения бизнес-процессов, который описывает полный процесс и
может использоваться для интеграции компонентов BPM при моделировании, исполнении и
контроле процессов в рамках продукта. XPDL также широко применяется в продуктах BPM
с открытым исходным кодом.
Шаг 5. Разработка ПО
В целом, можно выделить три слоя любого автоматизированного решения BPM:
1. представления решения пользователю;
2. обработки, содержащий автоматизированные задания;
3. интеграции с другими системами и базами данных, содержащими информацию.
Необходимо осознавать, что как в разработке, так и при тестировании каждому из этих
трех слоев нужен свой подход, поскольку задействуются разные группы людей.
Слой представления нацелен на конечных пользователей и видится ими в качестве си-
стемы. Необходимо учесть следующие факторы:
 знакома ли такая картина конечным пользователям и воспринимается ли она логично
(т.е. похожа на другие системы и представлена логичной последовательностью картинок на
экране);
 у различных типов пользователей будут разные потребности и способы взаимодей-
ствия с системой (например, работники, контролеры, менеджеры и т.д.).
Слой обработки связан с операциями, которые должна выполнять система. Необходимо,
чтобы она разрабатывалась людьми, хорошо понимающими бизнес и цели проекта. Важный
вопрос — документация, и при растущей популярности разработки пилотных инструментов
(RAD и BPM) налицо крепнущая тенденция не документировать вообще, или делать это не

6
Современными стандартами управления проектами являются: PMBoK, Agile, Scrum, Kanban
столь подробно, как следует. Разработчики утверждают, что документация неявно присут-
ствует в конфигурации системы, и ее можно там посмотреть. Вид системы дает представле-
ние о том, что было сконфигурировано, но не объясняет, почему была выбрана именно такая
конфигурация. Не видя решений, определивших конфигурацию, трудно вносить изменения в
будущем с какой-либо степенью уверенности, что они будут согласованы с выбранными ра-
нее вариантами процессов.
Слой интеграции / данных более технический, поскольку связан с интерфейсами других
систем. Требуются глубокие технические знания, а также четкое понимание систем, с кото-
рыми связаны автоматизированные решения BPM.
Один из наиболее остропроблемных аспектов этапа разработки ПО проекта не просто
относится к фактической разработке, но и к переходу на новую систему. Путь к успеху усы-
пан остатками проектов, в которых недооценивались проблемы, связанные с переходом и
интерфейсами.
С точки зрения рядового сотрудника переход может выглядеть просто, потому что един-
ственное, что требуется для переноса бизнес-моделей, процессов и данных из одной системы
в другую, — это простое соответствие полей данных между новой и старой системами. Но
очень важно, чтобы бизнес-модели, процессы и данные существующей системы были пра-
вильными. Опытные практики знают, что пользователи будут задействовать систему по-
разному, и это означает, что в ней окажется значительно больше ошибок, чем казалось на
первый взгляд.
Следует ли организации сначала перейти на новую систему, а затем вносить изменения,
или сначала внести изменения в существующую систему, а затем осуществлять переход на
новую? Часто второй вариант предпочтительнее, поскольку, как показали многие проекты и
организации, оказалось невозможным вносить изменения в систему, уже заполненную дан-
ными.
Выполняя подобный целевой анализ, важно различать важность, которую заинтересо-
ванные стороны придают своим требованиям. Очень практичен в этом смысле подход
MoSCoW в DSDM (динамичная методика разработки систем, см. www.dsdm.org), который
разбивает приоритет требований на следующие категории:
 M — строго обязательно;
 S — нужно, если вообще возможно;
 C — можно, если не влияет ни на что другое;
 W — не будет (в данном выпуске), но хотелось бы иметь впоследствии.
Путь 1. Традиционный (SDLC) подход к разработке
На рис. 19.6 показаны шаги, которые выполняются в традиционном подходе к разработ-
кам решения BPM по методу цикла разработки ПО (SDLC).
 Хотя такой подход проверен, апробирован и зарекомендовал себя при разработке реше-
ний, он необязательно лучший или наиболее подходящий подход к проекту BPM. Самый це-
лесообразный подход зависит от сценария, организации и объема проекта.
При традиционном подходе SDLC менеджер проекта должен вести регулярный монито-
ринг проекта, чтобы обеспечить его движение в правильном направлении в соответствии с
установленными требованиями и быть уверенным в том, что бизнес сохраняет поддержку
исходных спецификаций. Слишком часто после длительного периода разработки и тестиро-
вания проект выдает решение ПО, но оказывается, что бизнес-требования изменились.
Возможно, более удачен подход быстрой разработки приложений.
Путь 2. Быстрая разработка приложений
Большинство автоматизированных решений BPM дает возможность интерактивно кон-
фигурировать процессы между персоналом бизнеса и техническими специалистами, когда
специалисты по процессам и/или хозяева процессов садятся за стол вместе с техническим
разработчиком и «моделируют» автоматизированное решение. Этот подход особенно хорош
для сценария «пилотный проект» при изучении возможностей, которые открывает новое ре-
шение BPM. Он также быстро обеспечивает бизнес-подразделению общее представление о
решении. Но при моделировании целостного решения важно обеспечить наличие соответ-
ствующих спецификаций, чтобы провести тестирование, а также наличие документации для
будущих справок.
Столь же существенно, чтобы представители бизнеса, дающие информацию о процессах
и отвечающие за них, имели полное представление о конфигурации, ее месте в широком
контексте и последствиях вариантов, которые они выбрали. Если это непонятно, неизбежно
доминирование ИТ-компонента решения, когда у бизнеса нет достаточных знаний или влия-
ния на его разработку и результаты.
По мере дальнейшего совершенствования технологии BPM данный подход набирает
мощный импульс и обладает крупными бизнес-достоинствами.
Шаг 6. Аппаратное обеспечение
В понятие аппаратного обеспечения входят компьютеры для пользователей, серверы, се-
ти, а также офисная техника: принтеры, сканеры и носители для хранения данных.
Вопросы, которые необходимо учесть:
 совместимость — все ли системы могут общаться друг с другом, в частности, интер-
фейсы и платформы;
 масштабируемость/наращиваемость — можно ли расширять предлагаемые системы,
чтобы справляться со значительным ростом числа обрабатываемых транзакций;
 обслуживание и поддержка: все ли компоненты аппаратного обеспечения закреплены
за квалифицированным персоналом, способным обслуживать конкретный компонент (вклю-
чая средства резервирования и восстановления), а также обеспечивать поддержку пользова-
телей.
Наконец, убедитесь, что среда тестирования аппаратуры в точности такая же,как и бу-
дущая эксплуатационная среда. Многие системы прекрасно тестировались в «лабораторных»
условиях и «сыпались» в реальной эксплуатационной обстановке, потому что условия не
совпадали.
Шаг 7. Тестирование
Тестирование — важнейший шаг этапа разработки. В этот момент сравниваются разра-
ботанные системы приложений и исходные бизнес-требования, предполагая, что программы
тестирования и скрипты составлены правильно. Международная организация стандартиза-
ции (МОС) определяет тестирование так: техническая операция, заключающаяся в определе-
нии одной или более характеристик данного продукта, процесса или услуг, согласно уста-
новленной процедуре. (Воспроизводится с разрешения Центрального секретариата МОС с
веб-сайта Международной организации стандартизации www.iso.org.)
Более подходящее определение тестирования программного обеспечения: роцесс плани-
рования, подготовки, исполнения и анализа, направленный на установление характеристик
информационной системы и выявление разницы между фактическим и требуемым состоя-
нием. [57]
Тестирование имеет особое значение в ситуации фундаментальных или крупномасштаб-
ных изменений, а не для краткосрочных или небольших разработок. Поэтому тестирование
— важнейшая процедура, которая должна быть тщательно и разумно спланирована; ее нель-
зя отодвигать на слишком позднюю стадию проекта. План и программа тестирования долж-
ны быть выполнены в деталях при составлении бизнес- и функциональных спецификаций.
Если сценарии тестирования и программы-скрипты составлены на данной стадии, это даст
бизнесу и разработчикам более четкое понимание требований бизнеса. Будет понятна база,
по которой произойдет оценка системы, что должно еще больше снизить риски, связанные с
недопониманием между требованиями бизнеса и продуктами разработчиков.
Требуют учета следующие весьма серьезные аспекты:
 важно помнить, что на подготовку и планирование нужно отвести более половины
всего времени тестирования, а остальную часть — на фактическое проведение тестов;
 почти невозможно и весьма нежелательно выполнять 100-процентное тестирование,
поскольку затраты и сроки будут нереальны. Лучше практиковать структурированный под-
ход, добиваясь максимума эффективности при минимуме усилий. Руководитель тестирова-
ния должен всегда определять глубину тестирования, количество ошибок и «объем тестов».
Можно выделить следующие типы тестирования [57]:
 тест блока выполняется разработчиками в лабораторных условиях и должен пока-
зать, что данная работа или шаг автоматизированного решения BPM отвечает требованиям,
сформулированным в техническом задании;
 тест интеграции выполняется разработчиками в лабораторных условиях и должен
показать, что данная функция или аспект автоматизированного решения BPM отвечает тре-
бованиям, сформулированным в техническом задании;
 системный тест выполняется разработчиками в (надлежаще контролируемых) лабо-
раторных условиях и должен показать, что автоматизированное решение BPM или его ком-
поненты отвечают требованиям, сформулированным в функциональных спецификациях и
требованиях к качеству;
 тест функциональной приемки (FAT) выполняется системным менеджером и группой
тестирования в условиях, в максимально возможной степени имитирующих эксплуатацион-
ную среду. Он должен показать, что автоматизированное решение BPM отвечает требовани-
ям к функциональности и качеству, сформулированным в функциональных требованиях;
 тест приемки пользователями (UAT) выполняется пользователями системы. В «те-
невых» эксплуатационных условиях автоматизированное решение BPM будет испытано на
предмет соответствия требованиям бизнеса. Это включено в этап реализации;
 регрессионный тест предназначен показать, что все части системы по-прежнему
функционируют правильно после внедрения или модификации автоматизированного реше-
ния BPM. Регрессия — это явление, показывающее, что качество системы как целого не
ухудшается в результате отдельных модификаций.
Разумеется, нужно следовать обычному процессу тестирования:
1. определите показатели теста. Тестирование всегда предполагает баланс между выго-
дами от тестирования и связанными с ним затратами. 100-процентное тестирование — прак-
тически нереальное и чрезвычайно дорогостоящее мероприятие. TMap® — прагматичный
подход, описанный в [57].
2. Определите и опишите стратегию тестирования, которая должна включать тест бло-
ков, приемки пользователями (UAT), интеграции, регрессионный тест и т.д. Необходимо об-
думать используемую инфраструктуру.
Замечание: обязательно сделайте все возможное в рамках проекта, чтобы на стадии те-
стирования использовалась точная копия действующей среды инфраструктуры. Многие про-
екты развалились, если данное условие не было выполнено. Также помните, что не все тесты
относятся к системам приложений. В процессной среде большая часть тестирования враща-
ется вокруг «пробных прогонов» процессов в бизнес-подразделении и определения его при-
годности для заданной цели.
3. Составьте план тестов. Организация принимает решение о количестве и типах тесто-
вых конфигураций. Не забудьте привлечь все соответствующие заинтересованные стороны и
другие подгруппы проекта.
4. Опишите различные конфигурации тестов. Объем их будет зависеть от размера и
сложности проекта. Самое важное — охватить все вероятные сценарии.
5. Выполните тестирование. Завершите конфигурации и программы тестов.
 6. Проанализируйте результаты и решите, как двигаться дальше. Варианты: продолжать
реализацию, приостановить внедрение, пока не устранены ошибки, продолжить внедрение и
обеспечить внесение изменений по ходу или же скомбинировать три этих варианта.
Не все тесты фактически выполняются на данном этапе, но их нужно обязательно преду-
смотреть. Например, примененные тесты пользователей подготавливаются и осуществляют-
ся как часть шагов 3 и 5 этапа реализации.
Реализация ценности. Чтобы добиться согласия, необходимо тщательно определить вы-
игрыши как часть данного этапа. Подробности описаны в главе 21, шаг 5, в связи с реализа-
цией ценности в проекте.
Результаты этапа разработки

Этап разработки дает значимый вклад в другие этапы общей схемы (рис. 19.7), вот лишь
несколько примеров:
 решение может налагать требования на людей, которые будут работать с системой;
 этап разработки дает информацию для обучения на этапе реализации-внедрения;
 предложенная система может обеспечивать функциональность, которая дает бизнесу
дополнительные возможности, или же не обеспечить все функции, предусмотренные на эта-
пе инноваций, и в этом случае должны быть привлечены люди, готовившие спецификации
после этапа инноваций;
 этап разработки должен обеспечить устойчивое функционирование;
 разработка ПО может повлиять на изменения в архитектуре процессов (особенно со-
ответствующей информации и технологий).
Риски этапа разработки
На данном этапе присутствуют некоторые риски, так что нужно предусмотреть и реали-
зовать стратегии их исключения (или хотя бы снижения). Некоторые риски перечислены в
табл. 18.2 (см. выше).
В табл. 19.1 указаны риски и стратегии снижения, которые должны быть рассмотрены на
этапе разработки.
Таблица 19.1. Риски и стратегии их снижения на этапе разработки
Риск Стратегия снижения

1. Разработанное решение Обеспечение участия заинтересованных сторон по

не отвечает требованиям биз- всему ходу проекта
неса Полное понимание всех принятых решений и послед-
ствий
Разработка процессов и бизнес-обоснования (согласо-
 вание отклонений со всеми сторонами) на основе со-
гласованной архитектуры

2. Некоторые приложе- Не правильно работает один или несколько интерфей-

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

3. Тестирование выявило Обеспечение достаточной ясности и четкости требова-

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

Глава 20. Этап реализации. Назначение

На этапе реализации (рис. 20.1) все спроектированные и разработанные усовершенство-

вания процессов осуществляются в реальности. Здесь также сходятся вместе многие дей-
ствия по управлению изменениями персонала. Хотя это одна из последних частей всей об-
щей схемы и цикла проекта, ее следует рассмотреть в самом начале каждого проекта, с эта-
пом стартовой площадки, поскольку именно в начале проекта нужно принять решение отно-
сительно его внедрения в бизнес (подробности см. в главе 15). Решение о реализации окажет
влияние на такие грани проекта, как проектирование или перестройка процессов, выполне-
ние разработки и тестирование и т.п. К этому решению постоянно возвращаются по ходу
проекта, понимая, что метод реализации может измениться.
Кейс: запоздалая реализация в малом масштабе
Нас пригласили проанализировать не удачный BPM-проект. Его спонсор был поражен,
что проект не удался: все метрики были определены, технология работала, основные заинте-
ресованные лица получали сведения еженедельно, а пользователи готовились по проекту че-
рез масштабную кампанию расклейки постеров, рассылок по электронной почте и по про-
грамме интенсивного обучения.
Мы побеседовали с пользователями, и они сообщили, что с ними не посоветовались о
предлагаемых изменениях, которые строились на неверных предположениях, и на практике
не сработали бы. Когда мы поинтересовались у спонсора проекта, на какой стадии проекта
советовались с пользователями и сообщали им об изменениях, оказалось, что это было осу-
ществлено лишь после создания перестроенных процессов с помощью внешнего аналитика и
своих менеджеров.
Вывод. Пользователи должны привлекаться в проект на самых ранних стадиях, как,
впрочем, и все заинтересованные стороны.
Результаты
Если этап реализации завершен успешно, то организация может надеяться получить:
 обученный и мотивированный персонал;
  усовершенствованные или новые процессы, которые работают удовлетворительно,
согласно требованиям и нуждам определенных заинтересованных сторон и бизнес-
обоснованию.
Кейс: тест у кофейного автомата
Об участии заинтересованных сторон и пользователей часто говорят, но редко его доби-
ваются. Нам кажется, что можно легко проверить (простым и ненаучным способом), привле-
чены ли пользователи.
Подойдите к кофейному автомату в любой фирме и спросите у сотрудников о предлага-
емых улучшениях процессов. Если ответы будут вроде:
 «понятия не имею, чем они там занимаются»,
 «они провели увлекательные беседы, но я ничего не слышал в подробностях»,
 «нам они все равно ничего не говорят»,
знайте, что налицо явные признаки не вовлеченности пользователей и недостаточного
общения.
Нам приходилось сталкиваться с проектами, участники которых не пытались защитить
проект, когда о нем отзывались негативно. Часто это является проявлением неуверенности и
отсутствия гордости за проект, что может быть следствием не вовлеченности сотрудников.
Вывод. Неважно, насколько велики выгоды, которые вы намерены извлечь из проекта,
— если вы не донесете эти выгоды до заинтересованных сторон и пользователей, их будет
трудно достичь или реализовать.
Осуществление. Часто проекты не удаются, поскольку реализация сводится лишь к од-
ному из завершающих шагов проекта и сосредотачивается на одностороннем потоке инфор-
мации, сообщающем пользователям и другим заинтересованным сторонам о выгодах нового
решения для организации. Более того, большая часть работы нацелена на обеспечение спо-
собности пользователей применять новое решение (например, обучение), а не на то, чтобы
они хотели пользоваться им (например, мотивирование персонала).
Лучший способ обеспечить плавную реализацию — рассматривать вопросы реализации
еще при инициировании проекта. Только в этом случае этап реализации будет ориентирован
на обновление информации и выполнение задач, а не на придумывание в последнюю минуту
приемов, способных ублажить пользователей.
На рис. 20.2 представлены шаги, применимые к этапу реализации, которые рассматри-
ваются ниже.

Шаг 1. Обмен информацией

Хорошая реализация нуждается в хорошей коммуникации, включая двусторонние ком-
муникации. Активное участие пользователей даст отличные предложения и может также вы-
звать некоторые «интересные» (критические) замечания и неадекватные намеки. Но когда
пользователи осведомлены, почему их предложения или замечания не учитываются в общих
целях проекта, это дает более глубокое понимание того, чего мог бы достичь проект. Лучше
работать с обратной связью, чем игнорировать ее, вызывая потерю интереса и апатию. Также
важно понять, что некоторые обмены информацией могут фактически усилить, а не ослабить
сопротивление изменениям — так что всегда следите за методами общения и действиями.
Шаг 2. Обновление стратегии реализации
Стратегия реализации/внедрения должна быть определена еще в начале проекта. На эта-
пе реализации важно пересмотреть исходную стратегию реализации, поскольку:
 группа проекта и организация гораздо лучше будут понимать предлагаемые измене-
ния;
 стратегия должна принять во внимание текущую ситуацию, а она могла измениться
(и, скорее всего, изменилась) с момента начального определения стратегии реализа-
ции/внедрения.
В табл. 20.1 даются примеры типов стратегии, которые следует рассмотреть.
Таблица 20.1. Типы стратегии реализации
Сценарии ре- Замечания Преимущество Недостаток
ализации

«Большой Предлагаемые изменения осу- быстро реализуется высокий риск дез-

скачок» ществляются одним крупным скач- организации бизне-
ком са

Параллельный Предлагаемые изменения вносятся относительно понадобятся до-

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

Эстафета Предлагаемые изменения вносятся качество, посколь- малая скорость,

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

Комбинация Сочетание описанных выше подхо- дает организации

дов к реализации — возможно, не- возможность
большая опытная реализация, а за- настройки развер-
тем наращивание до крупного тывания на кон-
внедрения кретную ситуацию;
гибко, но все же
контролируемо
Сценарии реализации могут быть смоделированы, как показано на рис. 20.3.
 На шаге стратегии реализации еще раз рассматриваются различные типы пользователей
и заинтересованных сторон, а их ожидания и участие в проекте выверяются.
Шаг 3. Подготовка к тестам приемки пользователями
На этом шаге, если возможно, готовятся тестовые конфигурации для бизнеса. Требова-
ние тестирования решений фактические бизнес-пользователи относят к шагу 5 (выполнение
бизнес-тестов и опытных работ). У них будет возможность испытать готовое решение с точ-
ки зрения «обычной практики». К данной стадии проекта решение будет протестировано
лишь на соответствие письменным спецификациям бизнес-требований, тогда как новое ре-
шение также необходимо проверить на интеграцию с повседневной «текучкой» дел бизнес-
пользователей и неявными предположениями и ожиданиями.
В идеале, подготовка к бизнес-тестированию должна была начаться во время проектиро-
вания новых процессов (процесса). Это могло произойти либо на этапе инноваций, либо на
этапе разработки, в зависимости от конкретных обстоятельств. Если тестовые конфигурации
были разработаны на столь ранней стадии, то у организации имеется возможность сравнить
ожидаемые итоги тестирования с техническими и бизнес-спецификациями и схемами, чтобы
убедиться в отсутствии пробелов в требованиях. Такой прекрасный пример проверки позво-
ляет избежать дорогостоящих ошибок.
Шаг 4. Обучение и подготовка персонала
На этапе инноваций были разработаны новые процессы. Организация создала их и на
этапах разработки и работы с персоналом определила любые изменения в своей структуре,
ролевых и должностных инструкциях. Теперь настало время обучать и готовить персонал,
который будет исполнять эти процессы.
Как тестовые сценарии могут быть разработаны на основе перепроектированных про-
цессов, обучающие материалы можно создать на основе процессной документации перепро-
ектированных процессов.
Обучение может проходить в виде формальных курсов или обучения на рабочем месте.
Наставничество и тренировки должны продолжаться по ходу бизнес-тестирования, опытной
работы и начальной реализации.
Ясно, что используемые обучающие материалы должны быть согласованы, и обучение
нельзя начинать слишком рано. Лучше всего проводить обучение непосредственно перед
тем, как понадобятся определенные навыки (если научиться новым навыкам слишком рано и
не использовать их, они быстро забываются). Вот предложения касательно обучения:
 небольшие дозы обучения в точно рассчитанные моменты;
 индивидуальные обучающие семинары, чтобы люди знали, когда запланирована их
очередь (это создает уверенность и чувство сопричастности);
 проверка квалификации после обучения;
 мониторинг производительности на занимаемой должности после определенного пе-
риода времени.
Одним из итогов шага обучения персонала может быть формирование и обучение кате-
гории «супер-пользователей» в новых процессах. Это должен быть авангард на шагах реали-
зации.
Обучение должно быть нацелено не на одну ключевую область деятельности или какое-
либо автоматизированное решение, а охватывать такие аспекты, как:
 воздействия предложенного решения;
 определение «узких мест», которые будут «расшиты»;
  какие-либо новые «узкие места», которые могут возникнуть по предположениям
участников в период реализации;
 выгоды и возможности предложенного решения.
Шаг 5. Выполнение бизнес-тестов и опытных работ
На этом шаге бизнес - подразделение выполняет тестирование тестовых конфигураций.
Диапазон может меняться: от обработки данных или выполнения транзакций посредством
автоматизированного решения BPM, до ручной имитации «обработки» транзакций через
бизнес. Очевидно, персонал нужно обучить системе или процессам до начала этих тестов.
Важно, чтобы организация:
 привлекала клиентов и поставщиков, если целесообразно;
 осуществляла надежное управление шагами тестирования;
 имела простой в применении механизм обратной связи;
 искренне прислушивалась и общалась: абсолютно необходима обратная связь и вни-
мание к ней; на этом шаге можно многое понять и многое узнать;
 имела механизмы оценки результатов тестов и доведения их до сотрудников;
 была всегда готова вносить изменения на ходу и привносить их в цикл разработки
(продуктов разработки);
 распространяла информацию о результатах тестирования и опытных работ — демон-
стрировала успехи заинтересованным сторонам, особенно любые достижения и выигрыши;
но нужно всегда быть искренним в отношении любых проблем тестирования;
 получала заключения персонала, клиентов и поставщиков;
 отмечала успехи и вознаграждения членов групп (группы проекта и представителей
бизнес-подразделения).
Шаг 6. Обновление состояния выдаваемых продуктов
Речь идет об обратной связи с шагами обучения и тестирования. Важно постоянно акту-
ализировать ожидаемые результаты и обеспечить их принятие и одобрение заинтересован-
ными сторонами. Организация должна постоянно перепроверять, что ожидания всех заинте-
ресованных сторон, руководства и членов группы проекта по-прежнему согласованы, а объ-
ем внедрения понятен и также согласован.
Шаг 7. Участие руководителей
Руководство нужно постоянно держать в курсе всех событий (хороших и плохих). Чест-
ное общение — единственно приемлемый путь. Сделайте это общение интенсивным. В обя-
занности руководства входит постоянно информировать персонал и внешние заинтересован-
ные стороны о последних событиях проекта. Способы обеспечить участие руководства:
 работа по управлению изменениями персонала (см. главу 25);
 разработка профессионального обучения;
 выездные совещания (лучше проводить семинары вне объекта, чтобы внимание мене-
джеров не отвлекалось). Часто для проведения таких совещаний лучше привлечь внешних
посредников.
При необходимости привлеките компанию по связям с общественностью, если соб-
ственные силы для содействия этому недостаточны.
Общаясь с руководством, помните, что важно, чтобы сначала изменения произошли в
самих менеджерах, особенно, если эти предлагаемые изменения серьезно влияют на них.
Только после этого менеджеры могут помочь другим.
Шаг 8. Разработка планов развертывания, отхода и на случай непредвиденных си-
туаций
Для этого потребуются обычные навыки проектного управления, и мы лишь заметим,
что рекомендуется учесть следующее:
 составьте индивидуальные планы каждого бизнес-подразделения, привлеченного к
развертыванию системы;
 планы составляйте в тесном сотрудничестве с руководством и персоналом;
 запланируйте несколько совещаний, чтобы проект учитывал ошибки и учился на них,
соответственно подправляйте планы;
 обеспечьте предельную ясность ожиданий отдельных людей, чтобы не осталось ника-
кого недопонимания;
  введите практику пробных прогонов планов отхода (отступления назад) и непредви-
денных ситуаций; убедитесь, что они работают, и проводите пробные прогоны, пока не ис-
чезнут всякие сомнения.
Шаг 9. Разработка и запуск маркетинговых программ
Подумайте над целесообразностью запуска формальных маркетинговых кампаний на
рынке, конкретно нацеленных на внешние заинтересованные стороны. Организация даже,
возможно, сочтет необходимым опубликовать свою программу инноваций, подчеркивая но-
вые сильные стороны и конкурентные преимущества, которые она даст на рынке. Если будет
принят такой курс, любая объявленная рынку окончательная дата реализации должна быть
достигнута, иначе организация рискует утратить доверие заинтересованных сторон.
Часто отдельные или небольшие групповые встречи с ключевыми заинтересованными
сторонами дают им ощущение особой значимости и могут принести серьезные выгоды. Це-
лесообразно как можно раньше поделиться планами с важными клиентами и поставщиками
на условиях неразглашения.
Разумеется, какой бы подход ни выбрала организация, нужно использовать разнообраз-
ные методы маркетинга, а первостепенных клиентов должны информировать, насколько
возможно, должностные лица высокого уровня.
Шаг 10. Наставничество для персонала
Как упоминалось на шаге обучения, если сначала обучить избранных сотрудников как
«супер-пользователей», они смогут обучить остальной персонал и быть наставниками на
ранней стадии после реального запуска системы в эксплуатацию.
Важно, чтобы «супер-пользователи»/наставники были постоянно доступны на началь-
ном этапе реализации и не возвращались к исполнению своих обычных функциональных
обязанностей, пока реализация не осуществится. Нужно также предоставить наставникам
стимулы, чтобы они отвлеклись от повседневной работы и вложили время и усилия в проект.
Такие стимулы не обязательно должны быть денежными, но могут предусматривать новые
интересные роли и способ подтвердить способность сотрудников работать в проектах, что
может выражаться в продвижении по службе или признании заслуг внутри организации.
Шаг 11. Развертывание изменений
Эффективно выполнив «развертывание» процессов по организации, нужно обеспечить
недоступность для персонала «старых» процессов и систем поддержки. Существенно также
включить механизм постоянного усовершенствования. Более подробно это обсуждается в
главе 22.
Необходимо реализовать и изменения в подчиненности и структурной схеме организа-
ции, а также включение любых новых ролей и схем стимулирования, основанных на эффек-
тивности и производительности. Не стоит недооценивать сложность этого процесса или вре-
мя, которое он займет.
Шаг 12. Мониторинг и отладка
При распространении изменений значительные усилия следует посвятить мониторингу
процесса распространения изменений и продвижения к достижению бизнес-результатов.
Важно задать показатели для мониторинга продвижения. Вот некоторые примеры:
 количество заданных вопросов в первые недели (неделю);
 количество ошибок в первые недели (неделю);
 процент персонала, работающего с новыми процессами;
 уровень сверхурочной работы, необходимой для выполнения работы.
Шаг 13. Обратная связь с пользователями и заинтересованными сторонами
На протяжении всего проекта, а особенно, на этапе реализации, очень многое требуется
от бизнеса, бизнес-пользователей и заинтересованных сторон — их убежденность, вовлечен-
ность и участие. Нужно позаботиться о том, чтобы отблагодарить бизнес-подразделение,
бизнес-пользователей и заинтересованные стороны, постоянно держать их в курсе продви-
жений проекта и сообщать о различных усвоенных уроках.
Реализация ценности
Как на этапах разработки и работы с персоналом, на данном этапе необходимо подробно
определить выигрыши, чтобы заручиться согласием. Подробности описаны в главе 21, шаг 5,
в связи с реализацией ценности в проекте.
 Результаты этапа реализации
Этап реализации вносит значимый вклад в другие этапы общей схемы (рис. 20.4), и вот
лишь несколько примеров:
 то, как воплощен проект, окажет влияние на то, как будет проходить реализация вы-
игрышей (ценности) проекта;
 реализация также дает вклад в этап устойчивого функционирования;
 анализ и окончательная доработка подхода к реализации может потребовать измене-
ний этапов работы с персоналом и разработки. Например, может оказаться невозможным
сразу же перейти к вновь созданным ролям — переход, возможно, придется разнести по
времени.
Риски этапа реализации. На данном этапе присутствуют некоторые риски, так что нуж-
но предусмотреть и реализовать стратегии их исключения (или хотя бы снижения). Эти рис-
ки указаны в табл. 20.2.
Таблица 20.2. Риски этапа реализации и стратегии их снижения
Риск Стратегия снижения

1. Бизнес-тестирование и/или обучение Обеспечение как можно раннего об-

постоянно прерывают проект суждения:
 требований с бизнес-
подразделениями, основными пользо-
вателями и заинтересованными сторо-
нами
 ожиданий и последствий этих
требований

2. Главная группа проекта не способна  Привлечение «супер-

справиться со всеми проблемами и запросами пользователей» - обеспечение их:
на начальной стадии и ранних стадиях реали-  способности (путем обучения),
зации  готовности (занятие в проекте
на полный день)
 желания (путем мотивирования
и вовлечения).
действовать
 Формирование бригады «скорой
помощи», особенно на случай техниче-
ски сложной и детальной помощи

3. Заинтересованные стороны не инфор-  Общение, общение и еще раз

мируются о ходе проекта общение
Риск Стратегия снижения

 Поручение координации этой

работы конкретному лицу
 Обеспечение достаточного вре-
мени для решения этой задачи

4. У бизнеса нет знаний или ресурсов для  Некоторое «натаскивание» на:

проведения тестов приемки пользователями  составление плана тестирования
 написание программы тестов
 выполнения их.
 Группа проекта должна:
 проявлять осторожность
 «не перехватывать» эти задачи
 обеспечивать подсказки и
наставления.
 Переговоры и согласования объ-
ема требуемых ресурсов (людей) с биз-
несом на ранней стадии проекта

5. Если в проекте «туго со временем», то Если необходимо - отсрочка даты те-

первым делом урезают или сводят к миниму- стирования
му тестирование Нельзя экономить на тестировании

Глава 21. Этап реализации ценности. Назначение

Многие менеджеры проектов считают проект законченным, когда он воплощен в реаль-
ную жизнь, и довольны потребители. Ничто не может быть дальше от истины. Проект за-
вершен только тогда, когда исчерпана причина его разработки, проект передан бизнесу та-
ким образом, что бизнес сам теперь может поддерживать результаты проекта.

Ради чего проект затевался вообще? Это написано в бизнес-обосновании. Там должны
быть указаны выгоды и ценность для бизнеса, которые ожидается получить по окончании
проекта.
Ценность не падает сверху, как манна небесная. Выигрыши нужно планировать, они
должны быть кому-то нужны, на их материализацию нужно работать. Реализация бизнес-
ценности редко случается сразу после воплощения проекта (рис. 21.1), задержка может ино-
гда длиться от трех до шести месяцев (рис. 21.2).
 Иногда есть переходный период, на котором затраты даже растут на коротком интервале
после внедрения, и только потом начинает реализовываться ценность и снижаются операци-
онные издержки.
Есть также некоторое перекрывание затрат на проект и начало реализации ценности для
бизнеса, поскольку какая-то часть проекта должна продолжаться, пока не начнут реализовы-
ваться выигрыши, и проект не станет для бизнеса постоянной деятельностью.
Хотя для всех остальных этапов были указаны шаги, которые способствуют реализации
ценности, в этой главе эти шаги и схема управления будут сведены вместе, чтобы обеспе-
чить их полное понимание и, в конечном итоге, реализацию ценности проекта.
Если по ходу проекта оказывается, что ожидавшаяся ценность для бизнеса не может
быть реализована или просто перестала существовать, проект следует остановить. Это
ситуация станет очевидной, если постоянно вести и обновлять бизнес-обоснование по ходу
проекта (на каждом этапе).
В своей лекции в Университете Лидса в 2002 г. Дейвид Винни (David Vinney, специалист
в области инжиниринга информационных систем) указывал: последние исследования, прове-
денные школой бизнеса Университета Крэнфильда, показали, что 78% проектов с измене-
ниями на основе ИТ (в крупных британских компаниях) не принесли выгоды бизнесу. 47%
опрошенных считали, что оценка бизнес-выгод была слабой или плохой, а 79% сказали, что
не все имевшиеся выигрыши были обнаружены при оценке, а 45% считали, что выгоды про-
ектов в их организациях были явно завышены, чтобы получить финансирование.
На сайте правительства Соединенного Королевства (www.ogc.gov.uk, по состоянию на 8
июня 2005 года), утверждалось, что:
…многие проекты не обеспечивают выигрышей, на которые рассчитывали, когда
утверждали исходное финансирование. По оценкам специалистов, 30–40% систем под-
держки бизнес-изменений вообще не дают никаких выигрышей.
Это ужасная статистика, и ее вполне можно было избежать (или, по крайней мере, све-
сти к минимуму) в проектах BPM, следуя этапам общей методической схемы.
Общепринятый термин для обозначения контроля, управления и реализации бизнес-
ценности — управление выгодами. Управление выгодой преобразует цели бизнеса в выгоды,
которые можно измерять, отслеживать и реализовывать.
Если организация не старается упорно и тщательно осуществлять управление выгодами,
растет риск того, что проекты не смогут отвечать ожиданиям заинтересованных сторон. Ти-
пичный образец таких рисков приведен в конце этой главы.
Управление выгодами может также действовать как катализатор дальнейших изменений,
если проект не реализует ожидаемых выгод. Это может вынудить организацию провести
анализ, который может привести к смене подхода к проекту и, таким образом, последующей
реализации ожидаемой ценности.
Результаты
Есть целый ряд конкретных результатов и наработок, на которые бизнес может рассчи-
тывать по итогам данного этапа, в том числе:
 сводный план выгод;
 сетевая матрица сроков реализации выгод;
 матрица реализации выгод;
 реестр-журнал реализации выгод.
Осуществление
 Если необходимо реализовать бизнес-ценность, в проекте и в организации должен
иметься структурированный процесс - часть анализа выигрышей и затрат, связанная с выго-
дами. На рис. 21.3 показана среда управления выгодами.

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

ганизации и целями вкупе с запросами клиентов, а также типы выгод, открытые перед орга-
низацией. Другой заметный фактор воздействия — тип проекта изменения процессов, пред-
принятого в организации.
Чем предопределены организационные изменения:
1. культурой организации,
2. уровнем квалификации персонала или
3. переходом от функциональной к процессной основе структуры?
Эти связанные с проектом вопросы управления изменениями персонала имеют огромное
значение.
В грамотно реализованном проекте выгоды извлекаются легче и обеспечивают обратную
связь с исходными побудительными мотивами бизнеса и стратегией организации.
«Вызовом двадцать первого века все больше становится реализация сквозных измене-
ний на предприятии без границ».
Статья от 12 апреля 2005 года // www.ezinearticles.com,
Это означает, что у проектов BPM есть шанс стать чрезвычайно сложными, поскольку в
них могут вовлекаться несколько спонсоров из различных подразделений бизнеса и, воз-
можно, несколько организаций.
Однако спонсору и менеджеру проекта важно осознавать, что управление выгодами не
лежит за пределами проекта. В их обязанности входит планирование, управление и обеспе-
чение внутри группы проекта и, в конечном итоге, воплощение бизнес-ценности, сформули-
рованной в обосновании.
Реализация бизнес-ценности — процесс постепенный, и общая схема показывает, как
это достигается выполнением шагов на рис. 21.4.

Хотя в этой главе описан каждый из перечисленных шагов, выполнять их нужно на со-
ответствующем этапе.
Шаг 1. Схема управления выгодами (этап архитектуры процессов)
 Как указано выше, этот шаг предусматривает формирование структуры управления вы-
годами в организации, чтобы сформировать подход, поставить цель, измерять и реализовы-
вать бизнес-выгоды проекта. Все эти действия должны включаться в архитектуру процессов.
На данном шаге не только формируется структура управления выгодами, но и устанав-
ливаются стандарты и формы-шаблоны, которые распространяются по организации. Эти
стандарты и формы-шаблоны должны включать следующие описания:
 как организация идентифицирует выгоды и увязывает их со стратегий организации;
 как организация определяет и измеряет выгоды;
 роли выгод, ответственность и принадлежность «хозяину» (кто владеет);
 процедур планирования выгод — сетевых матриц сроков сдачи/выгод, точек осу-
ществления и рассмотрения, взаимозависимостей, рисков, влияния на бизнес;
 что, когда и кем делается;
 руководства по применению возможностей, открывающихся в результате непланиру-
емых выгод;
 выявления любых невыгод (ущерба);
 лиц, ответственных за установление отсчетной точки, каким образом устанавливается
такая отсчетная точка, кто ее утверждает;
 формата журнала реализации выгод — в чем выгода. Стоимостное выражение. Кто
отвечает за осуществление. Как осуществляются сроки — график. Когда отразится на бизне-
се.
Должны быть организованы регулярные обсуждения управления выгодами с принятием
решений о том, кто будет участвовать в них, и как часто их проводить, со стандартной по-
весткой:
 какие уроки извлечены;
 какие выгоды осуществились (хватит ли их; есть ли еще);
 выгоды не реализовались. Почему? Откорректируйте планы/стратегии смягчения
негативного эффекта и восстановления.
Шаг 2. Определение и планирование потенциальных выгод (этап стартовой пло-
щадки)
Исходное бизнес-обоснование составляется на этапе стартовой площадки, и в нем долж-
ны быть определены исходные вероятные выгоды, связываемые с проектом. По ходу проекта
на последовательных этапах общей схемы эти выгоды уточняются и подтверждаются. Жур-
нал реализации выгод необходимо использовать для регистрации по каждой установленной
и определенной выгоде следующих данных:
 описаний выгоды, которой нужно достичь;
 лица, ответственного за реализацию выгоды;
 описания текущей ситуации или функционирования бизнес-процесса;
 текущих затрат или мер эффективности бизнес-процесса;
 целевого показателя затрат или эффективности бизнес-процесса после планируемых
изменений;
 срока реализации выгоды;
 события, или «пускового» механизма, который вызовет реализацию выгоды;
 типа содействия бизнесу;
 оценки выгоды или экономии;
 взаимозависимостей;
 предположений;
 замечаний по стоимостной оценке выгоды или экономии;
 стратегии организации и целей, поддерживаемых достижением выгоды;
 каким образом данная выгода будет способствовать достижению стратегической це-
ли.
Выгоды можно также свести в сводную таблицу выгод (табл. 21.1). В этой таблице фик-
сируется сама выгода, лицо, ответственное за ее достижение (реализацию), предполагаемое
стоимостное выражение, сроки начала и окончания действий выгод (если это имеет место,
поскольку некоторые выгоды продолжат действовать в будущем), а также любые взаимоза-
висимости и риски, связанные с конкретной выгодой.
Таблица 21.1 Сводный план выгод
Описание «Хозяин» - Стоимость Ожидаемые сроки реа- Зависимости Риски
выгоды владелец выгоды лизации выгоды
выгоды
Начало Окончание

Данный шаг включает документирование и планирование управления выгодами, реали-

зация которых ожидается в проекте. Мониторинг именно этих выгод будет вестись на про-
тяжении срока существования проекта, а в конце проекта будет измерено и сообщено об их
достижении. Выгоды нужно также сравнить с бизнес-обоснованием.
Поскольку процессы могут распространяться на различные функциональные области,
это может сделать затруднительным измерение выгод BPM, но это не повод отказаться от
проведения измерений.
Группа проекта должна также принять во внимание, что в одном проекте могут быть,
как поддающиеся численному измерению, так и не измеряемые численно выгоды, связанные
с реализацией проекта.
Следует также иметь в виду, что само по себе улучшение продуктивности не переходит
в ощутимое снижение затрат, если его нельзя выразить в сокращении персонала, уходе от
дополнительных затрат или сокращении требуемых ресурсов. Ощутимой выгодой нельзя
считать микроскопические и малозаметные сокращения времени обработки, которые не ак-
кумулируются для нескольких сотрудников и не приводят к реализуемой экономии.
Кейс: не учитывайте экономию в мелочах
Нам случалось знакомиться со многими бизнес-обоснованиями на базе мелочных со-
кращений штатного персонала: например, здесь сэкономили 0,2 сотрудника на одном зада-
нии, еще 0,6 сотрудника на другом задании и т.д. Руководитель организации пожелал сло-
жить всю эту экономию вместе и сократить персонал. В лучшем случае, это чрезвычайно
трудно, а на практике неосуществимо, поскольку экономия на штатном персонале может
«расползаться» по нескольким должностям и функциональным обязанностям.
Вывод. Рассчитывайте только на выгоды, которые могут и будут реализовываться. Мел-
кие выгоды почти никогда не осуществимы на практике.
Советуясь с затронутыми бизнес-подразделениями, нужно установить целевые показате-
ли выгод, относящихся к проекту. Это показатели должны задавать временные рамки дости-
жения выгод, а также описания мероприятий, необходимых для достижения этих показате-
лей. Спонсор проекта отвечает за достижение установленных показателей выгод, соблюде-
ние сроков и выполнение мероприятий.
Комплексный план действий и журнал достижимых выгод теперь готовы, принимаются
ответственными бизнес-менеджерами (владельцами выгод) и утверждаются спонсором про-
екта.
Шаг 3. Установление точки отсчета для сравнения и сравнительных измерений
(этап понимания)
Как говорилось на этапе понимания, формирование метрик — важный момент при мо-
делировании действующих процессов, и именно от этой точки отмериваются улучше-
ния/усовершенствования. Поэтому при установлении отсчетной точки позаботьтесь, чтобы
она была строгой и выдержала испытания на прочность другими людьми, а также увязыва-
лась с бизнес-обоснованием. В идеале, все методы установления точки отсчета должны быть
согласованы с институционально закрепленной основой организации, которая была принята
в архитектуре процессов.
Шаг 4. Уточнение и оптимизация комплекса выгод (этап инноваций)
На этапе инноваций процессы перестраиваются на основе критериев, установленных на
совещаниях с руководством этапа. У перестроенных процессов должны быть рассчитывае-
мые метрики, чтобы оценить их влияние на возросшую эффективность работы.
Подтверждение выгод должно содержать пересмотр исходных отсчетных мер на пред-
мет точности и правильности и обновление с использованием новейших ставок затрат бизне-
са (например, зарплаты), особенно, если была задержка или интервал между этапами.
После этого нужно провести сравнение между новыми метриками этапа инноваций и
обновленными отсчетными метриками этапа понимания. При рассмотрении различных ва-
риантов перестройки процессов следует обратить внимание на «комплекс» вариантов (т.е.
состав) и его влияние на выгоды. Необходимо предпринять усилия для максимизации выгод
посредством выбора соответствующих вариантов процессов. В результате этого окончатель-
но формируются варианты процессов, а также обновленное бизнес-обоснование.
На примере рис. 21.5 в проекте на этапе инноваций требовалось рассмотреть три сцена-
рия перестройки процессов:

1. Три месяца (что можно сделать без каких-либо изменений в ИТ — мы считаем это
«быстрыми выигрышами»).
2. Восемнадцать месяцев (без автоматизации BPM; допускаются изменения существу-
ющих приложений).
3. Восемнадцать месяцев (полная автоматизация BPM, внедрение управления докумен-
тами и изменения в существующие приложения).
Спонсор проекта заявила, что не уверена, что реализация полностью автоматизирован-
ного решения BPM и системы управления документами будет экономически эффективна,
поэтому потребовала, чтобы перестройка процессов в проекте базировалась на двух 18-
месячных вариантах (с автоматизацией и без автоматизации), чтобы выяснить наличие до-
полнительных выгод.
Скачок выгоды A показывает сокращение затрат, которого можно достичь в результате
реализации быстрых выигрышей, что помогает их обоснованию. Скачок выгод B показывает
дополнительные измеряемые выигрыши, которые дает неавтоматизированное 18-месячное
решение. Скачок выгод D показывает измеряемое снижение затрат полностью автоматизи-
рованного решения.
Спонсора же проекта интересовал скачок выгод C — дополнительные выгоды, которые
можно извлечь из полностью автоматизированного решения. Именно анализ этого скачка
должен быть включен в бизнес-обоснование, чтобы оправдать потенциальные дополнитель-
ные затраты, связанные с решением BPM и управления документами.
(Предостережение: при обосновании полностью автоматизированное решение не долж-
но опираться только на измеряемые выгоды; есть множество нефинансовых выгод при внед-
рении этого типа решения, например маневренность бизнеса, повышение удовлетворенности
персонала и способность взаимодействовать с поставщиками и клиентами.)
Данное сравнение ставит перед комитетом по управлению проектом такой вопрос: отве-
чают ли рассчитанные выгоды ожиданиям, изложенным в бизнес-плане? Если ответ «нет»,
проект следует либо прекратить, либо вернуться на этап стартовой площадки, где выбирают-
ся различные комплексы процессов для работы в проекте.
Выполнив приведенный выше анализ, можно составить матрицу сдаточных сроков вы-
год (рис. 21.6).
 Эта матрица показывает взаимосвязи между различными проектами, сдаточными стади-
ями проектов и конкретными выгодами. Если на протяжении проекта взаимосвязи, непо-
средственно увязывающие сдаточные стадии с выгодами, не видны, выгода может исчез-
нуть, а сам проект (или его часть) следует остановить. Все члены группы проекта и предста-
вители бизнеса должны понимать эти взаимосвязи, особенно это относится к спонсору про-
екта, менеджеру проекта и владельцу бизнеса.
Необходимо обеспечить выяснение проблем при изменении бизнеса, чтобы их устране-
ние можно было отслеживать через реализацию выгод. Некоторые из проблем устанавлива-
ются еще в плане реализации выгод, другие возникают по мере разработки более подробных
планов управления изменениями персонала. Аналогично, в план реализации выгод должны
включаться скрытые выигрыши, выявленные во время реализации. Также необходимо раз-
работать сдаточные стадии и целевые показатели реализации выгод, связанные с деятельно-
стью по управлению изменениями персонала, чтобы можно было отслеживать продвижения
в реализации выгод в контексте этих действий по изменению персонала.
Шаг 5. Детальное определение выгод (этапы разработки, работы с персоналом и
реализации)
В начале этапа разработки после обновления плана проекта нужно заполнить матрицу
реализации выгод (рис. 21.7). Эта матрица показывает взаимосвязи между сдаточными ста-
диями проекта и выгодами, как описано в матрице сдаточных стадий выгод. Разница заклю-
чается в том, что сдаточные стадии и выгоды увязываются по времени, а затем постоянно
корректируются в связи с изменениями дат сдачи стадий (очередей) проекта. Заметьте, что
между завершением сдаточной стадии проекта и реализацией выгоды может быть разрыв,
как в примере с выгодой D на рис. 21.7.
 В этом примере:
 сдаточные стадии A1 и A2 были сданы согласно графику, что позволило реализовать
выгоду А в планируемую дату;
 сдаточная стадия A3 была просрочена, в то время как сдача стадий B1 и B3 прошла
по графику, что вылилось в реализацию выгоды B позже срока и реализацию выгоды C в
срок; задержка реализации выгоды В привела к затратам, связанным с задержкой;
 сдаточные стадии B2 и B4 были просрочены, что вызвало отсрочку реализации выго-
ды D, а это также вылилось в связанные с задержкой затраты.
Важно отслеживать задержку сроков, поскольку их невыполнение может повлиять на
организацию в самых разных аспектах, в том числе:
 наименьшие потери связаны со стоимостью потерь денежных средств в результате
несвоевременной реализации выигрыша до намеченного срока (расходы на проценты и дви-
жение денежных средств);
 упущенные возможности бизнеса (неспособность воспользоваться бизнес-
возможностью в силу не реализации проекта или сдаточной стадии); у некоторых бизнес-
шансов окно возможностей ограничено временем;
 дополнительные затраты по проекту, включая стоимость ресурсов на затянувшийся
срок;
 недостигнутые нормативы организации по прибыли (выполнение может переноситься
на другой финансовый год или квартал);
 недостаток человеческого ресурса для нового контракта.
Когда назревает нарушение сроков сдачи, понимание взаимосвязей стадий сдачи и выгод
подскажет группе проекта и бизнес-подразделению, куда направить ресурсы, чтобы полу-
чить максимальную выгоду для организации. Возможно, ресурсы следует перебросить с од-
них задач и проектов (выгоды которых менее ценны) на задачи с более высокой отдачей в
виде выгод.
Мониторинг продвижения с учетом сдаточных стадий реализации выгод должен быть
составной частью отчетности проекта и регулярных отчетов спонсору проекта и руково-
дящему комитету.
На этапе разработки нужно продолжать вести (обновлять) матрицу сдаточных стадий
выгод и матрицу реализации выгод и учитывать их на этапе работы с персоналом.
Шаг 6. Реализация и отслеживание выгод (этап реализации ценности)
В обязанности лица, ответственного за реализацию выгод входит:
 обеспечение осуществления всех мероприятий, указанных в сводном плане выгод;
 обеспечение наличия всех контролирующих структур, необходимых для реализации
выгод.
Планирование управления изменениями персонала должно считаться критически важ-
ным фактором успеха проекта; необходимо начинать его параллельно планированию реали-
зации проекта и фактически, вместе со всем проектом. Спонсор проекта и лицо, ответствен-
ное за реализацию выгод, должны обеспечить отражение в планах любых зависимостей
между деятельностью по реализации проекта, управлению изменениями персонала и меро-
приятиями по реализации выгод.
Реализовав выгоды, получите формальное подтверждение, внесите их в журнал и рас-
скажите людям.
Шаг 7. Мониторинг и получение максимальной ценности (этап устойчивого функ-
ционирования)
Поскольку выход на некоторые целевые показатели выгод опираются на работу после
завершения проекта, в пост-проектных обследованиях необходимо обеспечить проверку то-
го, что цели выгод достигнуты и продолжают реализовываться. Такая проверка должна
включать:
 внутренний аудит соответствия выгод целевым показателям, внесенным в журнал ре-
ализации выгод;
 рассмотрение планов проекта и журналов, чтобы убедиться в успешном завершении
всех мероприятий, связанных с реализацией выгод;
 рассмотрение реализации выгод, связанных с основными мерами по управлению из-
менениями персонала.
 Это не означает, что необходимо ждать окончания проекта, чтобы начать мониторинг
реализации его ожидаемой ценности. Посредством различных описанных выше матриц, а
также через аудит соответствия требованиям или аудиты проекта мониторинг следует вести
в течение всего срока существования проекта.
По завершении проекта необходимо предоставить полный отчет о достижении выгод
спонсору и хозяину бизнес-проекта. Если выгоды достигнуты полностью или даже превы-
шены целевые показатели, нужно просто зафиксировать такие ситуации. Если выгоды не до-
стигли целевых показателей более чем на 10%, в отчете необходимо проанализировать ситу-
ации, которые привели к невыполнению цели, и дать рекомендации о целесообразности ка-
ких-либо мер исправления. Полный анализ содействует более точным оценкам выгод и вно-
сит вклад в этап стартовой площадки других проектов.
В подобных вопросах необходимо участие отвечающих за данную область бизнес-
менеджеров, чтобы сверить правильность выводов и выявить области, где целесообразны
корректирующие действия. Если бизнес-менеджеры считают, что выгоды все еще можно из-
влечь, в консультациях с ними нужно установить новые целевые показатели.
В каждой из областей, где были согласованы новые целевые показатели, необходимо
совместно с отвечающим за данную область бизнес-менеджером разработать план меропри-
ятий. Ответственность за реализацию плана должна возлагаться именно на бизнес-
менеджера, ответственного за область, в которой будут реализовываться выгоды. Журнал
реализации выгод следует обновлять, чтобы отразить вновь согласованные целевые показа-
тели выгод.
Организация должна быть уверена, что достигла максимально возможных выгод от сде-
ланных вложений. Если выгоды не дотягивают до исходных ожиданий, нужно, по крайней
мере, понимать причины и возможности будущей корректировки.
Шаг 8. Обмен информацией
На этом шаге проектная группа и бизнес-подразделение общаются с более широкой мас-
сой в организации и нужными внешними заинтересованными сторонами. Доводимая инфор-
мация должна сообщать об успехах проекта и реализованных выгодах.
Этот обмен информацией также должен включать сведения о том, как выгоды будут
поддерживаться в организации в будущем, а также о мероприятиях и усилиях, требуемых
для обеспечения постоянства поддержания выгод.
Решающие факторы успеха. Каким образом организация обеспечит извлечение макси-
мума выгод из своих проектов? В этой главе предложен подход и приводятся некоторые
критически важные для успеха факторы:
 понимание, что реализация ценности должна быть теснейшим образом переплетена с
проектом и культурой организации и быть их важнейшей частью;
 необходимо планировать достижение выгод — сдаточные стадии и затраты;
 должно быть согласие относительно ролей, ответственности и подотчетности, связан-
ных с реализацией ценности;
 должны быть полностью установлены риски, связанные с не достижением реализации
ценности, и выработаны соответствующие стратегии их снижения;
 персонал, участвующий в реализации ценности, должен быть подготовлен, чтобы вы-
являть выгоды, анализировать и изучать их;
 необходимо иметь в распоряжении средства управления для отслеживания и приня-
тия итоговых мер;
 непредвиденные выгоды должны выявляться и регистрироваться;
 если возможно сравнение с другими организациями той же отрасли или в смежных
отраслях, надо такое сравнение провести;
 никогда не недооценивайте аспекты управления изменениями персонала проекта при
реализации ценности; если не заручиться поддержкой людей, будет чрезвычайно проблема-
тично добиться соответствия ожиданиям выгод проекта.
Итоги этапа реализации ценности
Этап реализации ценности вносит значимый вклад в другие этапы общей схемы (рис.
21.8), вот лишь несколько примеров:
 чтобы добиться максимума будущих выгод, данные обратной связи могут навести на
соображения о корректировке этапа реализации, чтобы добиться максимума будущих выгод;
это особенно ценно в случае постепенного распространения по организации, чтобы вноси-
мые в процесс распространения изменения обеспечивали максимум выгод;

 могут также предлагаться корректировки управления изменениями персонала;

 может прийти осознание необходимости изменений в методике разработки и выстра-
ивания новых процессов, опять же с целью максимизации выгод;
 накапливаются знания, способствующие устойчивому поддержанию результатов про-
екта.
Риски этапа реализации ценности
Обзор самых общих рисков, которые следует принять во внимание на этапе реализации цен-
ности, дан в табл. 21.2.
Таблица 21.2. Риски и стратегии их снижения этапа реализации ценности
Риск Стратегия снижения

1. Бизнес может не настроиться на реали- Менеджер проекта, группа архитектуры

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

2. Недостаточна нацеленность на реали- Менеджер проекта, группа архитектуры

зацию бизнес-ценности, описанной в обосно- процессов и спонсор проекта отвечают за
вании нацеленность проекта

3. Нереалистичны ожидания выгод, что Вносите в бизнес-обоснование и матрицы

затрудняет их реализацию с какой-либо сте- отчетности только реалистичные выгоды
пенью уверенности

4. Недостаточно структурирован подход Создайте систему управления выгодами

к реализации бизнес-ценности (выгод) как часть архитектуры процессов органи-
зации

Глава 22. Этап устойчивого функционирования

В этой главе описан этап устойчивого функционирования (рис. 22.1) — последний этап
общей методической схемы управления бизнес-процессами, который связан с необходимо-
стью перехода от проектного состояния BPM к обычному бизнес-режиму BPM. Хотя этот
этап — последний в общей схеме, он является первой стадией работы организации в повсе-
дневном режиме BPM.
 Как, якобы, сказал Стивен Шварц (Stephen Schwartz) из IBM: «У нас были программы
усовершенствований. Но реально разница ощущается, когда принято решение, что это уже
не программа, а стратегия бизнеса».
Назначение. Можно утверждать, что усовершенствование процессов без устойчивой эф-
фективности не стоит усилий, поскольку отлаженная практика быстро исчезает по мере из-
менений и развития бизнеса. Это усугубляется тем, что взращенные ожидания заинтересо-
ванных сторон не оправдываются в долгосрочном плане, а последнее, в свою очередь,
усложняет завоевание их доверия и уверенности в будущих проектах.
Цель данного этапа — обеспечить поддерживаемую устойчивость усовершенствований
процессов и сделать ее частью повседневной работы. Существенные вложения, сделанные в
любой проект, должны поддерживаться и укрепляться со временем, ни в коем случае не
обесцениваться. В организации должны понимать, что время жизни процессов ограничено, и
можно продолжать их усовершенствование после достижения целей проекта.
Поддерживаемая устойчивость определяется способностью организации создавать и
обеспечивать ценность для всех заинтересованных сторон постоянно. Суть дела — в пони-
мании того, что ценят заинтересованные стороны сегодня и в будущем, а это обуславливает
стратегию организации, структуру и побуждение к действию. Процессы нужно постоянно
совершенствовать и перестраивать, чтобы они отражали этот позыв к действию. В против-
ном случае процессы организации будут просто работать на субоптимальном уровне.
Другими словами, устойчивое функционирование означает непрерывное управление
процессами, нацеленное на достижение определенных показателей. В этой главе показано,
как именно процессы можно совершенствовать автономно, оценивая практику выполнения
работ и изыскивая возможные способы улучшений. Автономная рационализация, как прави-
ло, осуществляется небольшими шагами и в ограниченном объеме. Если объем расширяется,
то лучший подход — разработка четкого бизнес-обоснования проекта, а изложенная в этой
книге общая методическая схема является практическим руководством.
Результаты, достигаемые на этом этапе:
1. Механизмы (комплекс практических мер) по управлению бизнес-процессами, иден-
тификация и реализация возможностей усовершенствований бизнес-процессов.
2. Управляемые и усовершенствованные процессы.
Осуществление
Этап устойчивого функционирования реализуется в 10 шагов, которые показаны на рис.
22.2.
 Шаг 1. Оценка результатов проекта
Здесь сравнивается (модифицированное) исходное бизнес-обоснование с фактическими
итогами проекта (включая реализованную ценность). Проводится сравнение с исходной точ-
кой отсчета, чтобы определить:
 насколько быстрее выполняются процессы;
 насколько сократилось количество ошибок, объем переделываемой и просроченной
работы;
 насколько эффективны выполняемые процессы;
 насколько повысилась удовлетворенность клиентов;
 насколько повысилась удовлетворенность персонала;
 итоговый анализ затрат/выигрышей проекта;
 начали ли извлекаться выгоды, как предусматривалось.
У этой оценки есть две задачи:
1. внести необходимые поправки в действующий режим для устранения недостатков.
2. Учесть уроки, извлеченные в проекте, в соответствующих аспектах этапов стратегии
организации, архитектуры процессов и стартовой площадки, имея в виду последующие про-
екты. Другими словами, рассматривать совершенствование процессов как улучшение реали-
зации проектов BPM.
Шаг 2. Разработка/уточнение (на рисунке «отладка» - С.К.) стратегии устойчивой
эффективности функционирования
В проекте должна ставиться задача формирования механизма постоянной оптимизации
процессов и управления ими. Такая непрерывная оптимизация и управление должны быть
вложены в проект и переданы бизнесу управляемым способом.
Во многих организациях, запустивших проекты BPM, ожидаемые выгоды не реализова-
лись из-за недостаточного мониторинга и анализа работы новых процессов. Часто это
приводит к потере крупной части вложений в проект.
Ожидания и запросы организации, клиентов, поставщиков, фактически всех заинтересо-
ванных сторон меняются со временем. Стратегия устойчивого функционирования организа-
ции должна предусматривать несколько формальных механизмов, чтобы не просто обеспе-
чить поддержание вложений в эти процессы, но постоянный пересмотр применимости
процессов к существующей и ожидаемой в будущем операционной среде.
Организации должны регулярно пересматривать оценку взаимосвязей между бизнесом и
заинтересованными сторонами, возникающей стратегией и планами организации, а также
обнаруживать разрывы и находить их причину по мере их появления. После этого должны
быть обеспечены механизмы устранения этих разрывов, отладки процессов и решения про-
блем управления изменениями, возникающими в результате таких разрывов.
Устойчивое функционирование уже должно было быть предметом рассмотрения архи-
тектуры процессов, а также бизнес-обоснования и плана/графика проекта. Стратегия устой-
чиво эффективного функционирования должна отвечать на следующие вопросы:
 каковы показатели устойчивого функционирования?
 Что входит и что не входит в сферу устойчивого функционирования?
 Каковы функции и обязанности в связи с устойчивым функционированием?
 Как вознаграждается персонал за вклад в устойчивое функционирование?
Шаг 3. Включение мер эффективности функционирования в управление
 Для достижения устойчивого функционирования важно, чтобы процессы управлялись, а
управление процессами требует непрерывного измерения эффективности их функциониро-
вания.
В идеале измерения должны быть увязаны с общими показателями работы организации,
чтобы обеспечить настройку процессов под эти показатели и оценку их вклада в достижение
таких показателей. Более того, необходимо соотносить измерение процессов с оценкой со-
трудников-участников. Другими словами, эффективное функционирование должно возна-
граждаться.
Сбалансированная система показателей — отличный способ измерения процессов, по-
скольку она не только охватывает краткосрочные финансовые аспекты, но и дает взгляд из-
нутри и видение перспективы клиента. Фактически, важно, чтобы любая утвержденная сба-
лансированная система показателей учитывала все нужды и ожидания заинтересованных
сторон. Другое преимущество использования таблиц сбалансированных показателей состоит
в том, что они напрямую увязывают эффективность функционирования процессов с показа-
телями эффективности организации и привязывают инициативы к заданным показателям.
Это подчеркивает важность тщательного выбора индексов таблиц.
Не следует каскадным методом распространять подход таблиц сбалансированных пока-
зателей на всю организацию. Этот подход чрезвычайно полезен для первых трех верхних
уровней структуры организации, но при переходе к более низким уровням меры эффектив-
ности должны быть простыми (ясными для понимания) и необязательно напрямую связан-
ными с общими показателями. Подобные измерители эффективности должны быть сформу-
лированы на этапе работы с персоналом.
Следует помнить, что при определении измерителей производительности процессов
нужно учитывать несколько аспектов, включая:
 эффективность (в том числе качество),
 экономичность (в том числе затраты и время),
 адаптируемость,
 риски,
 удовлетворенность клиентов и
 многое другое.
В разных частях организации движущие силы будут различными.
Постоянное измерение должно стать ключевым компонентом в определении измерите-
лей процессов и целевых показателей производительности. Необходимо обеспечить возмож-
ность сравнивать целевые измерения с фактическими результатами на выходе процесса. Су-
ществует, тем не менее, несколько способов измерений:
 видение перспектив и ожидания заинтересованных сторон;
 ожидания руководителей (хотя «руководство» является заинтересованной стороной,
это особый случай, и ожидания руководства должны быть выполнены). Ожидания руковод-
ства должны быть выражены количественно. Обычный способ такого выражения — KPI.
Качественные меры также могут измеряться посредством KPI.
Однажды определенные меры должны позволять супервайзерам организации, главам
групп и менеджерам сфер деятельности работать на упреждение, меняя штат, перебрасывая
сотрудников и ресурсы ради немедленного устранения «узких» мест и обеспечивая входные
данные для необходимых изменений процессов.
Другие варианты измерений могут быть следующими:
 сравнительные измерения в отрасли организации с ее конкурентами, а также вне от-
расли, где такие сравнения можно в разумной степени выполнить и получить значимые ме-
ры;
 обеспечение детального понимания и принятия хозяевами процессов своей роли
(помните: не всякому процессу нужен свой хозяин — некоторые процессы слишком мелкие,
а другие просто недостаточно важны, чтобы оправдывать наличие хозяина);
 предоставлены ли «хозяевам» процессов письменные должностные инструкции и
KPI?;
 процесс управления изменениями персонала должен предусматривать предоставление
полномочий сотрудникам;
 централизованный детализированный мониторинг, дающий уверенность, что страте-
гия непрерывного совершенствования срабатывает;
  отладка подхода с учетом извлеченных уроков;
 постоянный анализ применимости установленных мер производительности в процес-
се изменения и движения бизнеса, что ведет к изменениям способов измерений.
Сравнительные измерения с точками отсчета. Когда организации начинают измерять
эффективность процессов, часто возникает вопрос их сравнительной оценки между подраз-
делениями внутри организации или с конкурентами. Выбор точки отсчета позволяет прово-
дить такие сравнения. Перед сравнением численных показателей с другими организациями
важно понять все используемые допущения и определения, чтобы иметь уверенность в сопо-
ставимости чисел. Слишком часто организации сравнивают числа, не имея представления о
разнице в сфере, сложности или культуре.
Установление точки отсчета может быть увязано со временем производственного цикла,
обработки, затратами, качеством, удовлетворенностью клиентов и рентабельностью. Точка
отсчета может также устанавливаться на различных уровнях, например уровне продукта,
процесса, бизнес-подразделения и организации.
Шаг 4. Петли обратной связи
Выше уже подчеркивалось, что BPM — это управление бизнес-процессами, оно включа-
ет две составляющие:
 сами процессы и
 управление ими [40].
Чтобы руководство организации могло управлять соответствующими бизнес-
процессами:
1. должна быть определена одна (или более) мера эффективности функционирования.
Такие меры содержат критерии эффективности, по которым будут оцениваться процессы, и
включают количественные (например, финансовый показатель) и качественные меры
(например, удовлетворенность клиентов).
2. У руководства должна быть модель опорных сквозных процессов, которые дают воз-
можность менеджерам понять эффекты действий, выбранных руководством. Частично это
будет документировано (например, модели процессов), частично — не будет (например,
уроки, извлеченные из предшествующих проектов или усилия по выполнению измерений).
Следует внимательно следить, чтобы выбираемые меры функционирования поощряли пове-
дение, которое руководство хочет сформировать или воспитать.
3. У руководства должно быть достаточно информации о состоянии процессов; это от-
носится не только к результатам на выходе, но и к таким характеристикам процессов, как
ошибки, основные проблемы, незаконченная и переделанная работа.
4. У руководства должно быть достаточно мер контроля, чтобы справиться со связан-
ным уровнем неопределенности и изменений. Имеющиеся меры воздействия должны быть
достаточными, чтобы справиться с ожидаемой переменчивостью обстоятельств.
5. У руководства должно быть достаточно информации о возможностях обработки, что-
бы принимать информацию и проверять ее (например, обнаруживать «шум» и несоответ-
ствия в данных). Чтобы разобраться в данных и принять необходимые меры, требуется
наличие способностей и времени.
6. Если достижение итоговых результатов представляется трудным или невозможным,
руководство должно обратиться к более высокому уровню управления и обсудить, как по-
ступить в сложившейся ситуации.
В организации также должны понимать, что разные уровни руководства будут по-
разному подходить к управлению процессами:
 на стратегическом уровне изменения и неопределенность более высоки, но и в распо-
ряжении менеджеров есть больше управляемых переменных: усовершенствования процес-
сов, реинжиниринг процессов, сотрудничество, переход к другой бизнес-модели или даже
аутсорсинг. У менеджеров, отвечающих за стратегию организации, обзор шире, но их взгляд
более подвержен флуктуациям, чем у операционного руководства;
 На операционном уровне изменений и неопределенности меньше, но и управляемых
переменных меньше; например, больше или меньше ресурсов и возможность эскалировать
(поднять) проблему на более высокий уровень управления;
 Нормативы для руководства низшего уровня устанавливаются руководством более
высокого уровня.
 Определив показатели, важно создать обратную связь, чтобы обеспечить постоянное со-
вершенствование процессов. Деминг предложил свой механизм: подход «план-действие-
сверка-реакция» (Plan-Do-Check-Act) [78], показанный на рис. 22.3.

Руководство не только получает информацию из самой обработки, но и до (связь впе-

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

В случае обратной связи (рис. 22.5) фактические конечные результаты процесса измере-
ний можно сравнить с нормативами или целевыми показателями процесса (например, термо-
стат, регулирующий нагревание или охлаждение по разнице между фактической и желаемой
температурой). Важно понимать, как нужно «подстроить» процесс, чтобы при его следую-
щем исполнении он был лучше настроен на достижение нормативов или показателей обра-
ботки. Это может потребовать корректировки самого процесса или предоставленных ресур-
сов (например, выделить больше людей или отправлять транзакции на обработку более или
менее квалифицированным сотрудникам).
Преимущество петли прямой связи в том, что она предвидит новые ситуации. Недоста-
ток же в том, что трудно получить всю необходимую информацию, а затем определить влия-
ние на процессы.
Преимущество петли обратной связи в том, что она позволяет точно измерить степень
достижения процессом нормативов или показателей. Недостаток же в том, что она дает ин-
формацию после завершения процесса, и может оказаться слишком поздно достигать норма-
тивов или показателей.
Ясно, что лучше сочетать обе формы «кольцевания» информации, чтобы обеспечить
предвидение, мониторинг, управление и коррекцию. Но чрезвычайно важно, чтобы инфор-
мация по обратной связи позволяла руководству увидеть не только проблемы, связанные с
процессами, но и измерители, которые позволят вести мониторинг обратной связи. Это поз-
волит лучше понять, как на процессы влияют изменения обстоятельств и/или соответствую-
щие действия руководства.
Обратная связь не должна ограничиваться конкретным шагом процесса, поскольку она
связана со сквозным видением бизнес-процесса. Большинство ошибок, задержек и наруше-
ний происходит при сквозном видении процесса, особенно когда сотрудники, вызывающие
проблему, и сотрудники, испытывающие на себе ее воздействие, не знают друг друга и поня-
тия не имеют о действиях друг друга. В такой ситуации можно предпринять следующие ша-
ги:
 прямая связь: в начале процесса происходит изменение по сравнению с обычной
практикой (например, поступление большего, чем обычно числа заявок), дальнейшие шаги
процесса могут получить информацию об этом и принять упреждающие меры;
 мониторинг: хозяин сквозного процесса должен вести мониторинг протекания про-
цесса и обеспечить его прохождение согласно плану;
 обратная связь: если в конце процесса не удалось достигнуть нормативов или показа-
телей (например, время обработки запросов клиентов), нужно сообщить об этом соответ-
ствующим сотрудникам. Доведение петли обратной связи до нужного сотрудника — важ-
нейший фактор. Часто обратная связь обеспечивается предшествующим шагом процесса, что
ведет лишь к субоптимизации, если не работать со сквозным процессом.
Кейс: обратная связь — вклад в сквозные процессы – на семинар!!!
В банке наблюдался рост количества ошибок при обработке ипотечных займов. Тради-
ционный подход передачи информации работникам на предшествующих шагах процесса не
дал результатов. Тогда мы пригласили на семинар участников сквозного процесса. После
этого был смоделирован обобщенный процесс, и каждому из приглашенных было предложе-
но указать свои основные проблемы. Всем участникам стало ясно, что многие ошибки до-
пускаются на ранней стадии процесса. В то же время работники, занятые в начале процесса,
не осознавали важности, нужности и значения некоторых вводимых данных и решений, ко-
торые ими принимались. Прозрачность процесса и обмен этими знаниями позволили значи-
тельно сократить количество ошибок. Важно также, что каждый понял весь сквозной про-
цесс и получил возможность впервые встретиться со своими коллегами — участниками про-
цесса. Это позволило спокойно ощущать себя при появлении новых проблем, в контактах
друг с другом и при решении вопросов.
Вывод. Обратная связь должна быть увязана с полным сквозным процессом, а не огра-
ничиваться предыдущим его шагом.
Обратная связь может осуществляться на различных уровнях и для различных людей:
 личная обратная связь: например, сотруднику по обработке требований возмещения
ущерба сообщается, что его решение по конкретному требованию неверно, с указанием при-
чины и правильного решения;
 обратная связь с руководством: например, менеджеру по требованиям возмещения
ущерба сообщается о количестве требований, которые нужно переработать повторно в связи
с неверной начальной оценкой;
  обратная связь процесса: например, процесс обработки требований пересматривается,
если обнаруживается слишком много ошибок. Пересмотр включает документацию процесса
и обучающие материалы, что может привести либо к изменениям в документации (напри-
мер, более четкое изложение), либо к корректировке самого процесса.
Шаг 5. Встраивание устойчивой эффективности
Постоянного совершенствования процессов можно достичь, только если люди придер-
живаются правильного способа применения усовершенствованных процессов. После внед-
рения новых процессов персонал может вернуться к старым методам работы, если его не
убедили в преимуществах новых усовершенствованных процессов. Другая причина может
заключаться в недостаточно глубокой подготовке, обучении или поддержке внедрения, по
причинам которых сотрудники просто забудут детали новых процессов. Это может означать
либо возврат к старым способам или процессам, либо изобретения «на лету» индивидуаль-
ных процессов.
Один из способов поддерживать новый процесс и руководить персоналом на начальных
стадиях его исполнения — разместить информацию о процессе во внутренней сети органи-
зации вместе со всей сопровождающей информацией (механизмами включения, действиями,
которые должны выполняться, предполагаемыми результатами, инструкциями / руковод-
ствами, информацией о хозяине процесса, системами и документами, имеющими отношение
к процессу, и т.п.). Это может дополняться вспомогательной и поддерживающей информа-
цией, например, какими формами нужно пользоваться, какие документы иметь в виду, на
какие сайты обращаться за консультацией, или даже, какие приложения использовать. При-
менение моделей процессов в качестве ключа к поиску всей этой информации имеет два
главных преимущества: во-первых, люди действительно будут сверяться с процессами, а во-
вторых, у всех будет доступ к самой последней новейшей версии документации.
Устойчивая эффективность BPM может быть достигнута, только если процессы поддер-
живаются в самом последнем актуальном состоянии; важность этого невозможно переоце-
нить.
Когда начинаются семинары по моделированию, часто спрашивают: «Зачем снова моде-
лировать процессы? Мы в прошлом году этим занимались». Если же поинтересоваться ре-
зультатами прошлогоднего моделирования, с удивлением обнаруживается, что во многих
случаях модели процессов невозможно отыскать, не говоря уже об их фактическом приме-
нении. Наилучший способ поддерживать актуальное состояние процессов и информации,
связанной с ними, — размещать ее во внутренней сети организации, дав сотрудникам про-
стую обратную связь по всем шагам процессов и возможность выдвигать идеи по их рацио-
нализации.
При размещении процессов в сети важно придерживаться ориентации на пользователя:
что хотят видеть пользователи информацией, и как лучше всего им ее предоставить. Модели
процессов и вся связанная с ними информация должны помещаться в общем хранилище, и у
различных категорий пользователей должна быть возможность получать разные картины,
виды, типы и срезы информации. Например, аналитиков процессов могут интересовать зада-
ния, которые должны выполняться, персонал ИТ будет больше интересоваться взаимосвязя-
ми систем, процессов и документов, а финансовый департамент — обработкой финансовых
операций и разделением функций. Нужно также подумать, какой объем информации предо-
ставлять различным типам пользователей: например, информация о рисках и проблемах,
связанных с процессами, возможно, нужна не всем сотрудникам.
Следует ли размещать процессы на сайте для клиентов, поставщиков и партнеров? Зна-
ние процессов может дать им видение изнутри операций, которые должна выполнить орга-
низация, и возможность отслеживать ход процессов. Следует проявлять осторожность в свя-
зи с предоставляемой информацией с точки зрения конфиденциальности и защиты служеб-
ной тайны.
Размещение информации и моделей процессов во внутренней сети, как описано выше,
потребует соответствующего инструмента управления и мониторинга процессов.
Хороший способ ввести устойчивое поддержание управления бизнес-процессами в кон-
це проекта — организовать Центр совершенствования бизнес-процессов для бизнес-
подразделений. Более подробно об этом сказано в главе 28.
Анализ процессов, выявление «узких мест» и областей совершенствования, а также при-
нятие соответствующих мер должно стать для организации «способом существования». Ис-
полнители процессов часто знают проблемы, но не могут или не готовы объяснить их тем,
кого это волнует (или должно волновать). Чтобы люди делились проблемами, необходимо
создать благотворную обстановку. Назвать и сообщить имена хозяев процессов также озна-
чает указать тех, кого заботят процессы.
В Японии практикуется хороший подход к внедрению процессного мышления в работу
каждого сотрудника (Кайдзан). Эта концепция подразумевает непрерывное постепенное
усовершенствование на трех уровнях: руководство, группы сотрудников и индивидуальные
работники. «Кай» означает «меняться», а «дзан» — «хорошо» или «правильно». Руководство
стремится улучшить системы и процедуры, группы сотрудников нацелены на усовершен-
ствования процессов (петли обратной связи) и достижение нормативов, а работники стре-
мятся улучшить свою рабочую среду. Это позволяет постоянно понемногу совершенствовать
процессы, и действует на «цеховом» уровне. Предложения крупных изменений подаются хо-
зяину процесса. Преимущество небольших усовершенствований в том, что они обычно реа-
лизуются просто и быстро, а результаты налицо. Это также дает сотрудникам ощущение
значимости и личного вклада в развитие организации.
Шаг 6. Вознаграждение за поддерживаемую эффективность
К сожалению, совершенствование процессов и улучшение управления процессами в ор-
ганизации вознаграждается недостаточно или даже не вознаграждается вовсе. Лучший спо-
соб вознаграждения — по итогам и результатам, что означает не только финансовые и объ-
емные показатели, но на начальном этапе, возможно, поощрение инициатив. Когда BPM уже
развернулось, руководство может переключиться на систему вознаграждений, более привя-
занную к итогам и результатам. Принятая система вознаграждений не должна ориентиро-
ваться на краткосрочные достижения (получение месячной или квартальной премии), не
обеспечивая длительных результатов (для этого, очевидно, нужен более долгий цикл возна-
граждения). Везде есть примеры, когда успешные BPM-инициативы содержали схему возна-
граждения участников. Известно, что Джек Уэлш (Jack Welsh) из General Electric поставил
большую часть премии своих менеджеров в зависимость от их результатов во внедрении ше-
сти сигм. В других организациях прохождение обучения или получение сертификата в обла-
сти процессов является условием для включения в список кандидатов на повышение по
службе.
Кейс: вознаграждения ведут к успеху
Организация связи несколько раз пыталась усовершенствовать процессы и связанные с
ними системы, но все эти попытки не давали желаемых результатов. Анализ предпринимае-
мых усилий показал, что предложения и подход к их реализации были правильными. Но
дальнейший анализ выявил, что руководители участвовали в инициировании проекта, но не
следили за его реализацией. Работы выполнялись сотрудниками, которые оценивались и
вознаграждались за свой обычный повседневный труд, и считалось, что они занимаются
проектом по доброй воле. Этим объяснялось снижение поддержки усовершенствований.
Каждому бизнес-подразделению был выделен наставник по процессам, а схему преми-
рования выстроили так, что значительная часть зависела от успеха работы в проекте, а
остальное – от обычной работы. В результате, работники, занятые в проекте, не просто про-
должали свое участие в нем, но и еще больше были настроены на результативность.
Вывод. Нацеливание работников с помощью осмысленной схемы вознаграждений дает
результаты.
Шаг 7. Институциализация руководства процессами
Осуществление корпоративного руководства стало важнейшим требованием в большин-
стве организаций и бизнес-сообществ. Мы бы определили руководство процессами как
«управление, контроль и отчетность процессов внутри организации». Требование корпора-
тивного руководства побуждает организации учитывать интересы всех заинтересованных
сторон: работников, финансирующих структур, акционеров, государственных органов, кли-
ентов-потребителей, поставщиков и широкого сообщества.
«Руководство» как понятие не ново — оно «на слуху» в организациях уже много лет. Но
происходит радикальный переход от добровольного принятия кодексов поведения организа-
циями или отраслью к более строгому - требуемому законодательством (например, закон
Сарбанеса-Оксли 2002 года). Это переход ускорил недавний крах нескольких крупнейших
организаций, показывающий, что саморегулирование достаточно затруднительно. Более то-
го, все больше организаций принимает методики правильного руководства, хотя от них этого
и не требуется, или соблюдает добровольные стандарты, например стандарты EFQM (Евро-
пейский фонд управления качеством) и МОС.
Как воздействует необходимость «руководства» на управление бизнес-процессами? Есть
два уровня воздействия: на сами процессы и на управление ими.
Воздействие на процессы связано с увеличением регламентирующих и нормативных
правил, применяемых к процессам. С этим лучше всего справиться, включив схему «руко-
водства» в архитектуру процессов (которая является основой для разработки новых процес-
сов, пересмотра и оценки существующих). Архитектура процессов должна обеспечить:
 прозрачность процессов;
 подотчетность каждого шага процесса и ответственность за весь сквозной процесс;
 выдачу необходимой отчетности процессов.
Воздействие на управление бизнес-процессами связано с тем, что требование «руковод-
ства» процессами заставляет организации принимать все необходимые меры, чтобы обеспе-
чить контроль и управление процессами и их надлежащее администрирование, что может
включать:
 строгое следование процессам;
 выявление всех исключений и нежелательных результатов на выходе с принятием не-
обходимых мер менеджером процессов;
 регистрацию и запись трассировки всей отчетности и действий, предпринятых мене-
джерами процессов;
 выявление и принятие адекватных мер в случае несоответствия требованиям норма-
тивных актов, рисков и слабых мест процессов.
Осуществляя проект BPM, менеджер проекта должен обеспечить учет требований,
предъявляемых к руководству процессами, на каждом этапе общей схемы, делая руковод-
ство процессами частью общего подхода организации к BPM.
С точки зрения «руководства» процессами заслуживают внимания следующие сообра-
жения [3]:
1. постоянные измерения. Предусматривают полный цикл: от определения ожидаемых
результатов в начале проекта, измерения продвижений в их достижении до оценки степени
осуществления результатов. Необходимо также учесть извлеченные уроки и применять их в
будущих проектах. Помните, что измерения имеют смысл, только если руководители приме-
няют извлеченные из них выводы и обеспечивают правильное распределение функций и
обязанностей с учетом этих уроков.
2. Разделение лидерства. Многие менеджеры стремятся полностью взять под контроль
все аспекты процесса, но попадают в одну и ту же ловушку: чем больше им хочется контро-
лировать, тем больше времени это отнимает и тем менее эффективно, так что они сами со-
здают себе проблемы. Поэтому менеджеры могут реально управлять процессами, только ко-
гда все понимают, чего от них хотят, и за что они подотчетны.
3. Хороша практически любая схема руководства. Самое главное — выбрать методику
руководства и осуществлять ее. Не очень важен выбор новейшей или самой полной методи-
ки. Решающим фактором является адекватность модели руководства для организации, соот-
ветствие ее целям и неуклонное применение.
4. Поощрение нужного образа действий (поведения). Должна быть обеспечена под-
держка и поощрение правильного выполнения людьми требуемых действий. Руководители
располагают широким спектром мер, которые можно использовать для этого: от стимулов до
наказаний. Старшие руководители играют важную роль, показывая пример. Более того, пра-
вильное поведение должно быть включено в оценку показателей работы.
5. Аллергия людей на чрезмерный контроль. Чрезмерный контроль не улучшает работу
сотрудников. Адекватные меры контроля должны стать неотъемлемой частью рабочей среды
каждого сотрудника и, как лидерство, должны делегироваться.
6. Будьте проще. Руководители часто попадаются в ловушку слишком сложных моде-
лей, что неизбежно вызывает осложнения. Если модель контроля слишком трудна для пони-
мания, она становится менее эффективной.
Шаг 8. Мониторинг поддерживаемой эффективности
Необходим не только мониторинг процессов, но и мониторинг и оценка реализации про-
грамм BPM. Другими словами, «соблюдайте то, что проповедуете». Лучший способ добить-
ся этого — сразу же установить достижимые нормативы. Возможные меры:
  удовлетворенность клиентов, партнеров и сотрудников внутренними программами и
сервисами BPM (опросы, анкеты);
 частота обращений к моделям процессов для справок/сверок;
 количество жалоб работников, что модели процессов неверны или не поддерживают-
ся в обновленном состоянии;
 количество описаний моделей процессов, которые не рассматривались или не моди-
фицировались в установленные сроки;
 текучесть кадров (внешняя и внутренняя);
 процентная доля проектов, которые достигли поставленных нормативов и заверши-
лись в срок и уложились в выделенный бюджет;
 наличие моделей процессов;
 длительность цикла моделирования процесса.
Проповедники BPM внутри организации должны отдавать себе отчет, что основной упор
на данной стадии делается на правильное исполнение процессов. Новые инициативы следует
начинать только:
 при наличии бизнес-обоснования, и
 если бизнес и/или руководители твердо нацелены на осуществление этих инициатив.
Нельзя начинать новые инициативы, просто потому что есть ресурсы BPM. Изменения
процессов нельзя осуществлять без участия бизнес-подразделений.
Шаг 9. Обмен информацией
Когда проект переходит от проектной фазы к повседневному режиму работы, обще-
ние/обмен информацией необходимо сосредоточить на реальных выгодах, которые были ре-
ализованы, и мотивации людей с целью выявления других областей для изучения и стимули-
рования их работы согласно новым процессам. Важно подчеркивать, что каждый новый про-
ект приближает организацию к процессно-ориентированному мышлению и функционирова-
нию.
Шаг 10. Поддержание моделей процессов
Процессы динамичны, поскольку они адаптируются к новым внешним и внутренним об-
стоятельствам. Таким образом, описания процессов нужно модифицировать, чтобы они от-
ражали эти изменения. Любые изменения процессов должны рассматриваться как запрос-
требование и следовать такому порядку:
1. Регистрация изменения (например, кто затребовал изменение).
2. Определение типа изменения и его приводные механизмы.
3. Ранжирование изменений в порядке приоритета.
4. Оценка воздействия.
5. Получение утверждения на изменение.
6. Планирование осуществления изменения.
7. Осуществление изменения.
8. Анализ реализации изменения.
9. Реализация ценности
Частью данного этапа является мониторинг и максимизация ценности. Подробности
описаны на шаге 7 главы 21, в контексте реализации ценности в проекте.
Результаты этапа устойчивого функционирования
Этап устойчивого функционирования вносит значимый вклад в другие этапы общей
схемы (рис. 22.6), особенно в этапы стратегии организации и архитектуры процессов, а из-
влеченные уроки пригодятся на этапе стартовой площадки будущих проектов. Полученный
из повседневной практики опыт дает знания, которые могут внести изменения в оба этих
этапа в последующих проектах и в режиме повседневной деятельности.
 Риски этапа устойчивого функционирования
В табл. 22.1 приведены наиболее часто встречающие риски, присущие устойчивому
функционированию, и стратегии их снижения.
Таблица 22.1. Риски этапа устойчивого функционирования и стратегии их снижения
Риск Стратегия снижения

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

функции хозяина процессов и хозяева процессов были определены еще на этапе запус-
управления процессами ка — это наиболее важный фактор успеха BPM

2. Персонал не придержива- Узнайте, почему персонал не хочет работать по-новому,

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

3. Процессы не обновлены Убедитесь, что персонал применяет модели процессов и

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

4. От рядовых сотрудников Поощряйте предложения рядовых сотрудников и млад-

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

5. Трудно поспевать за фор- Поход к корпоративному руководству должен быть все-

мулированием требований к сторонним, а не по частям
корпоративному руководству
компанией

Глава 23. Неотъемлемые атрибуты: введение

Десять описанных выше этапов не гарантируют успеха проекта BPM, поскольку это
многогранное и разноплановое мероприятие. Поэтому мы выделили три атрибута:
 управление проектом,
 управление изменениями персонала и
 ведущая роль, лидерство.
 В Кембриджском словаре слово «неотъемлемый» объясняется как «необходимый,
насущный, без чего не прожить». Мы считаем, что проект BPM не может существовать без
этих трех неотъемлемых атрибутов.
Неотъемлемый — это такой аспект проекта, который считается чрезвычайно важным,
практически критическим фактором обеспечения успеха проекта, но не проявляется в виде
последовательности действий и не наступает в определенный момент проекта. Атрибуты
прослеживаются на протяжении всего проекта, поэтому мы их показали отдельно на рис.
23.1.

Хотя десять этапов общей схемы тоже не являются жестко последовательными операци-
ями, поскольку пересекаются и накладываются друг на друга, они большей частью следуют
описанному порядку. Методики и сценарии, описанные в части II, дают примеры использо-
вания и схемы и последовательности шагов.
Атрибут считается фундаментальным условием успеха проекта и свойством, которое
пронизывает весь проект и проявляется на каждом его этапе. Это фундаментальная основа,
на которой зиждется любой успешный проект BPM. Если атрибуты сформированы надежно,
то основа будет, как гранит, в противном случае она будет походить на зыбучий песок, а
«тренога» проекта BPM (см. главу 11) наклонится, провалится или просто рухнет.
Об управлении проектом, изменениями персонала и ведущей роли написано достаточно
подробно в бесчисленных статьях и книгах. Мы не станем описывать все аспекты методоло-
гии успешного управления проектами, осуществления комплексной программы изменений
персонала во всей организации или качества, делающие человека настоящим лидером. Мы
остановимся лишь на аспектах, которые насущно необходимы для проекта BPM, — аспек-
тах, недостатки или недобросовестное осуществление которых сильно скажется на успехе
проектов BPM. Наше внимание будет посвящено частям каждого атрибута, которые бизнес-
подразделение и группа проекта должны отработать, чтобы проект был успешным.

Глава 24. Управление проектом. Назначение

Это глава — не руководство по управлению проектами. Предполагается, что как дисци-
плина управление проектами уже понимается. Задача состоит в том, чтобы сосредоточиться
на аспектах управления проектами, которые требуют особого внимания в проекте BPM, что-
бы увеличить шансы на успех.
 Управление проектами рассматривается как один из неотъемлемых атрибутов схемы
проекта BPM (рис. 24.1). Организация и группа проекта не смогут обеспечить его успех без
отлаженного управления. Достаточно ли быть хорошим менеджером проектов? Мы сказали,
что нет. Хороший менеджер проекта уже не означает просто знания и навыки, подходящие
для традиционных методологий проектного управления. Менеджеры проектов BPM должны
обладать прочными навыками:
 управления изменениями персонала;
 управления взаимоотношениями с заинтересованными сторонами;
 глубокого знания и опыта реализации проектов BPM.
Можно было бы согласиться, что для хорошего проектного управления достаточно двух
первых качеств; просто проекты BPM требует более глубоких знаний и их лучшего приме-
нения, чем раньше. Традиционно проекты, выполняемые по методикам проектного управле-
ния, были нацелены на изменения бизнеса на основе технологий автоматизации или при сла-
бом сопротивлении изменениям. Это обеспечивало уверенность в результатах, которая нуж-
на спонсорам проекта. Изменения BPM отличаются в одном важном аспекте: они почти
наверняка требуют крупных изменений в людях и/или организационной культуре.
Почему? Взглянем на любого менеджера крупной организации, управляющего неэффек-
тивными процессами. В девяти случаях из десяти ему хорошо известно о неэффективности
процессов, впрочем, как и вышестоящему начальству и большинству исполнителей. Когда
для исправления ситуации приходит практик BPM, который осознает, что заинтересованные
стороны понимают неэффективность процессов, естественно предположить, что реализовать
усовершенствования будет легко. Разумеется, это неверно.
Отличие проектов BPM — в воздействии на людей и культуру бизнеса. Глубинные при-
чины, интересы и цели, которые требуют перемен в работе, часто не осознаются, не пони-
маются и не рассматриваются. Мы вторгаемся в область, где очень не хочет оказаться тради-
ционный менеджер проекта, — здесь все неопределенно, риски высоки и трудно управляе-
мы. Менеджер проекта BPM должен быть весьма искусен, чтобы преуспеть в такой среде. В
табл. 24.1 даются некоторые способы добиться этого.
Таблица 24.1. Традиционное управление проектом и управление проектом BPM
Традиционное управление проектом Управление проектом BPM

Обеспечить, чтобы объем проекта давал опре- Обеспечить, чтобы объем проекта давал
деленность результата достижение бизнес-целей посредством
усовершенствованных процессов

Управление заинтересованными сторонами Управление заинтересованными сторонами

обеспечивает только реализацию проекта обеспечивает реализацию проекта и долго-
срочные изменения в поведении персонала
и устойчивость изменений для бизнеса
Традиционное управление проектом Управление проектом BPM

Планирование непредвиденных ситуаций Препятствия культурным изменениям

охватывает только очевидные и легко опреде- (иногда до 50% всех усилий проекта) и
ляемые риски планирование непредвиденных ситуаций
для неочевидных и трудно определяемых
рисков должны быть встроены в план про-
екта

Для обеспечения определенных результатов Работать со спонсором, руководящим ко-

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

Критерии успеха проекта определяются ис- Критерии успеха проекта в равной степени
ключительно количественными задачами определяются количественными и каче-
ственными показателями
Вопрос заключается в том, может ли обычный менеджер внедрения приложений или
бизнес-проекта успешно реализовать проект BPM? Ответ — условное «да» (вероятно), но
далеко не так успешно, как с этим справиться опытный менеджер проектов BPM. При уча-
стии неопытного менеджера проектов BPM или менеджера проектов с ограниченным опы-
том BPM риски будут просто значительно выше, и есть шанс, что организация не получит
выгод, которых можно достичь посредством BPM.
Для организации важно назначить собственного менеджера проекта, даже если у него
нет опыта реализации проектов BPM. Чрезвычайно важно, чтобы этот менеджер был челове-
ком из бизнеса, а не назначенцем отдела ИТ: ИТ, поставщик решения и остальные составля-
ющие проекта должны подчиняться этому бизнес-менеджеру проекта BPM. Для поддержки
неопытного менеджера проекта нужно прикрепить к нему опытного консультанта BPM вы-
сокого ранга (внешнего или внутреннего). Помимо этого вклад такого опытного консультан-
та в проект может состоять в следующем:
 объективно разрешать ситуации, когда необходим компромисс в ходе проекта (такие
ситуации неизбежны), так как последствия таких решений весьма серьезны. Специалист
BPM должен быть способен правильно контролировать риски, чтобы проект BPM не пре-
вратился в дорогостоящий проект мелких улучшений;
 сохранить целенаправленность проекта, самофинансирование (насколько возможно) и
реальную отдачу в виде бизнес-ценности;
 обеспечить правильное внесение в план проекта необходимых элементов управления
изменениями персонала и культуры как существенной частью проекта;
 обеспечить постоянное участие заинтересованных сторон, удовлетворение их нужд и
нацеленность на успешное внедрение BPM.
Может ли человек, не имеющий существенного опыта управления проектами, реализо-
вать проект BPM? Ответ на этот вопрос прост — нет. Умение управлять проектами — фун-
даментальное требование или необходимость для любого проекта, и проект BPM не является
исключением; только требования, возможно, выше в силу возросшей сложности.
Результаты
При правильном управлении проектом существенно снижаются риски, а вероятность до-
стижения целей организации в проекте и реализации выгод повышается.
Во всех проектах должны выполняться обычные требования корпоративного руковод-
ства организации на весь срок существования, что предусматривает методика проекта, кото-
рой придерживается его менеджер.
Осуществление
Существует множество методик управления проектами и им посвящено множество книг,
так что мы не предлагаем новую, а рассмотрим два главных аспекта управления проектом с
точки зрения BPM:
  во-первых, есть несколько «шлюзов», которые нужно пройти удачно, чтобы проект
BPM был успешным, да и просто продолжался;
 во-вторых, взаимодействие с заинтересованными сторонами.
«Шлюзы» проекта
«Шлюз» — это ключевой контрольный пункт или стадия сдачи по ходу проекта. На под-
ходе к такому шлюзу он всегда считается закрытым, пока менеджер и спонсор проекта не
сочтут, что имеется достаточно информации, чтобы открыть шлюз и продолжить проект. Ес-
ли же шлюз остается закрытым, поскольку имеющаяся информация неудовлетворительна,
проект нужно остановить, пока не поступит информация, позволяющая открыть «шлюз».
Частично закрытый шлюз означает, что информация неполна, и проект нужно приостано-
вить до получения более полной информации.
Мы опишем несколько «шлюзов», которые могут встретиться по курсу проекта. Невоз-
можно, да мы и не намерены пытаться, перечислить все шлюзы, поскольку каждый проект
индивидуален. При планировании проекта главные шлюзы нужно определить как можно
раньше:
 в точках, где бизнес может выйти из проекта или приостановить его, если необходи-
мо, снизить риски и затраты организации;
 стратегии выхода из проекта необходимо планировать и согласовать при определении
шлюзов - в стратегических точках, обеспечив создание ценности для организации к этому
моменту, независимо от точки выхода из проекта.
Шлюзы имеют номера для ссылок — это не последовательность шлюзов в проекте.
Шлюз 1. Изучение заинтересованных сторон
Одним из первых действий в проекте должно быть определение, последующее изучение
и анализ заинтересованных сторон, включающий перечисленные ниже составляющие:
 стиль лидерства заинтересованных сторон (см. главу 26, где подробно классифициро-
ваны и рассмотрены стили лидерства/руководства);
 понимание места внутренних заинтересованных сторон в структуре организации, и ее
иерархии;
 понимание движущих бизнес-мотивов внутренних заинтересованных сторон (органи-
зации) и их личных мотивов; как правило, бизнес-мотивы обычно отражаются в основных
областях результатов и показателях производительности конкретных лиц; однако личные
мотивы (амбиции) внутренних заинтересованных лиц могут быть очень важным стимулом
для конкретного сотрудника.
.
Шлюз
закрыт, пока обычно открывается, когда
 не оценено общее состояние заинте-  согласованы и увязаны с достижением
ресованных сторон итогов:
 не получены ответы на вопросы:  сообщество заинтересованных сторон
 настроены ли заинтересованные сто-  BPM-зрелость
роны на предлагаемые изменения (проект)?  цели проекта BPM
 есть ли рассогласования?  запланированы шаги, которые могут:
 возможно, большинство заинтересо-  быть правильно выполнены
ванных лиц нацелены на проект, а ключевые  проконтролированы
ответственные за принятие решений фигуры  объединить заинтересованных лиц
и источники влияния нет?
 насколько зрелы в смысле BPM от-
дельные лица и организация в целом?

Более подробно перечисленные действия рассматриваться в следующем разделе этой

главы (взаимодействие с заинтересованными сторонами).
Шлюз 2. Осознание размаха изменений
Масштабность изменений и организованность заинтересованных сторон в определенной
степени привязаны к сценарию реализации. В сценарии «обычная работа» можно ожидать,
что заинтересованные стороны настроены на проект. Сценарий «рулевой», по всей вероятно-
сти, требует большего масштаба перемен и нацеленности заинтересованных сторон, чем
сценарии «пилотный проект» или «вне поля зрения».
 На начальных стадиях планирования проекта - на этапе стартовой площадки - группе
проекта нужно определить и документально зафиксировать требуемый размах изменений и
нацеленности заинтересованных сторон, как они видятся на этом этапе.
Масштаб перемен далее уточняется на этапе инноваций, когда становится ясно, как
должны меняться процессы, и заполняется матрица способностей персонала.
Должно присутствовать очень четкое понимание масштабности изменений, требуемых
организацией. Пока понимание не достигнуто, нельзя двигаться дальше, поскольку такое по-
нимание приводит нас к следующему шлюзу проекта — способности организации к измене-
ниям.
Кейс: определение проблемы бизнеса
Организация планировала многомиллионный проект внедрения системы управления
клиентами (CRM), чтобы решить проблемы:
 колл-центра,
 хранилища данных,
 выборки и анализа данных,
 масштабной функции очистки данных для их точности и
 системы управления документами.
Было проведено совещание с участием заинтересованных сторон, чтобы определить
бизнес-проблему, которую должен решить проект. Через три часа заинтересованные стороны
не смогли ее сформулировать. Руководители просто хотели внедрить какую-нибудь «новую
систему», и внешние консультанты рекомендовали ее. Было найдено техническое решение
для несуществующей пока проблемы.
Мы предложили разбить проект на небольшие части и сделать обоснование каждой из
них. Это предложение проигнорировали, и менеджер проекта провел год, агитируя заинтере-
сованных людей и пытаясь написать бизнес-обоснование. Проект так и не сдвинулся с мерт-
вой точки.
Вывод. Поговорите со всеми заинтересованными людьми, обсудите с ними необходи-
мость проекта и проблему, которую он должен решить, еще до формулировки бизнес-
обоснования или хотя бы до его окончательного варианта.
Шлюз
закрыт, так как обычно открывается, когда
1. бизнес-подразделение и/или  согласован объем изменений
группа проекта не понимает объем из-  проведена оценка воздействия
менений из-за:
 неясности эталонных (свероч-
ных) процессов,
 недостатка информации о функ-
ционировании организации,
 различий в запросах заинтересо-
ванных сторон и т.д.;
2. неизвестно воздействие измене-
ний на организацию
Трудности с определением объемов часто возникают, поскольку бизнес-проблема, кото-
рую пытается решить организация, не сформулирована как следует и не согласована между
бизнесом и заинтересованными сторонами. Это очень важный шаг, и он должен быть проду-
ман и выполнен до окончательной доработки бизнес-обоснования.
Шлюз 3. Способность организации к изменениям
Сущность проекта BPM такова, что он, безусловно, приводит к изменениям в организа-
ции. Масштаб перемен может быть от скромного до значительного, но в большинстве проек-
тов BPM масштабность перемен лежит в диапазоне от средней до огромной.
Возможность (и способность) организации меняться подвергается испытанию в проекте
BPM, и ее нужно выяснить в самом начале проекта, поскольку если проект требует значи-
тельных изменений, а степень зрелости организации не позволяет ей справиться с масшта-
бом требуемых изменений, проект обречен на неудачу в зародыше. В такой ситуации мене-
джер проекта должен обратиться к спонсору проекта и принять решение о курсе действий,
что может включать отказ от проекта или его остановку. Гораздо полезней определиться с
этим в начале проекта, чем потратить время и деньги, а потом обнаружить, что организа-
ция не способна измениться в требуемой степени.
В главе 27 мы поможем менеджеру и спонсору проекта проверить зрелость организа-
ции, чтобы справляться с изменениями.
Шлюз
закрыт, так как обычно открывается, когда
 организации:  оценена и понята BPM-зрелость органи-
 излишне уверенны в способно- зации;
сти иметь «все и сразу»  оценена способность к изменениям
 могут не осознавать свою спо-  оценена скорость изменений:
собность изменяться  высокие цели разбиты на небольшие
 склонны недооценивать потен- этапы:
циал восприятия изменений  предусмотрены небольшие из-
 не определен разрыв между же- менения с последующими мелкими
ланием перемен и объективной реаль- улучшениями
ностью  снова шаг изменений и опять
мелкие улучшения и т.д.

Шлюз 4. Принятие BPM организацией

BPM-зрелость организации также связана с пониманием ею значения процессов и влия-
ния, которое усовершенствование процессов может оказать на достижение целей и реализа-
цию стратегии организации.
Процессно-ориентированные взгляды организации определяются ее BPM-зрелостью,
пониманием BPM руководителями и их вниманием к процессам.
Этот шлюз часто закрыт, потому что:
 руководители слишком увязли в решении текущих проблем;
 руководители не осознают значимости процессов для эффективности функциониро-
вания организации.
Этот шлюз часто открывается:
 давлением, оказываемым рынком, которое вынуждает организации изучить возмож-
ности сокращения затрат, сосредоточившись на процессах;
 растущей готовностью к BPM и расширением практики успешных реализаций BPM в
других организациях;
 одним руководителем, успешно реализующим сценарий «пилотный проект» или про-
ект «вне поля зрения», чего часто бывает достаточно при демонстрации выгод BPM для ор-
ганизации.
Шлюз 5. Техническое исследование
Если проект BPM предусматривает автоматизацию и взаимодействие с существующей
инфраструктурой (оборудование, сети, существующие системы приложений), на ранней ста-
дии проекта необходимо провести техническое исследование, чтобы убедиться, что выбран-
ное решение BPM действительно способно состыковаться с требуемой инфраструктурой.
Если это технически невозможно или требуются значительные расходы, весь проект может
остановиться.
Такое соображение кажется очевидным, но в неоправданно большом количестве проек-
тов оно не предпринимается на ранней стадии.
Этот шлюз часто закрыт, потому что:
 существующая техническая инфраструктура неизвестна, плохо описана документаль-
но, непонятны интерфейсы, технологии несовместимы и т.д.
Этот шлюз часто открывается:
 техническим анализом на начальной стадии проекта;
 тщательным выбором комплекса инструментария по автоматизации BPM (и подтвер-
ждением поставщиком решения функциональности такого инструментария на опытной де-
монстрации в процессе выбора).
Кейс: инфраструктурный барьер
 Мы руководили проектом внедрения автоматизированного BPM у клиента, где инфра-
структура распадалась по мере невообразимого роста организации. Это ставило интересные
проблемы в связи с действующей инфраструктурой.
Мы сказали клиенту, что проект следует временно приостановить и провести пилотное
исследование взаимодействия выбранного решения BPM с существующей инфраструктурой,
поскольку существовали опасения, что старые приложения могут потребовать существенных
переделок, чтобы влиться в решение BPM. Клиент проигнорировал этот совет и настоял на
продолжении внедрения, поскольку этого жестко требовал бизнес.
Через несколько месяцев проект пришлось остановить, поскольку без значительных пе-
ределок нельзя было совместить интерфейс с инфраструктурой. Если бы проект приостано-
вили вовремя, доработки можно было бы вести параллельно с другими аспектами проекта
BPM, избежав задержек и расходов.
Вывод. Если есть подспудные серьезные проблемы инфраструктуры, с ними нужно
разобраться на ранней стадии проекта, определить и знать их воздействие; это сэкономит
время и деньги.
Управление взаимоотношениями заинтересованных сторон
Во-первых, нужно решить, кто же они, эти самые заинтересованные стороны (лица). За-
интересованная сторона — это лицо или группа лиц, у которых есть (или они считают, что
есть) интерес (положительный или негативный) в проекте. Это самые разные люди: от от-
дельных менеджеров, сотрудников, поставщиков решений до бизнес-подразделений, по-
ставщиков, клиентов, каналов-дистрибьюторов, а также сообщество, окружающая среда и
рынок.
Взаимодействие с ними очень важно, а мы рискнем предположить, что для проекта BPM
критически важно, в силу ряда причин:
1. без основных внутренних заинтересованных лиц у проекта не будет финансирования.
2. На этапах понимания и инноваций мы предположили, что нужно изучать процессы
непрерывно, что почти наверняка означает пересечение границ подразделений и организа-
ции. Без поддержки основных заинтересованных сторон достичь этого нельзя.
3. Без поддержки основных заинтересованных сторон чрезвычайно трудно реализовать
бизнес-выгоды, определенные в бизнес-обосновании.
4. В проекте BPM участвуют многие: бизнес-подразделения, члены подгрупп проекта,
поставщики, клиенты и т.д., и без их поддержки и энтузиазма проект просто становится
труднее.
5. Некоторые внешние заинтересованные стороны могут играть важнейшую роль, и их
нужно определить.
Особо следует направить общение и информирование на различные группы.
Кейс: привлечение внешней заинтересованной стороны
Мы занимались проектом BPM, в котором большая часть бизнеса расходилась по по-
средникам. Наша задача состояла в перестройке процессов, которые создали эти посредники.
Когда мы предложили сформировать небольшое количество целевых групп заинтересо-
ванных лиц, чтобы разъяснять посредникам, чего хочет добиться организация, выслушать их
проблемы и обеспечить применение процессов, мы столкнулись с сопротивлением отдела
продаж и убеждением, что это необязательно.
Но когда клиент понял необходимость таких встреч, он стал привлекать посредников в
проект, и результаты оказались прекрасными.
Вывод. Как можно рассчитывать, что внешние заинтересованные стороны будут приме-
нять процессы после внедрения, если они не привлекаются к созданию этих процессов?
Взаимодействие с заинтересованными сторонами — это целиком и полностью управле-
ние взаимоотношениями, что являет собой структурированный процессный подход к необ-
ходимым взаимоотношениям в рамках проекта. В силу сложности проектов BPM такое вза-
имодействие должно быть более формальным процессом, чем в традиционных проектах.
Как создать такой более формальный структурированный процесс взаимодействия с за-
интересованными сторонами?
Есть два типа управления взаимодействием, обычно требующихся для успеха проектов
BPM:
1. «управление взаимодействием для успешной реализации» использует, скорее, фор-
мальный способ обеспечить выполнение заинтересованными сторонами поставленных перед
ними задач ради реализации проекта. Основан он на достаточно традиционных методах про-
ектного управления, нацеленных на реализацию, и на представлении о враждебности /
недоброжелательности среды окружения, т.е. считается, что большинство компаний по-
прежнему работает в неблагоприятном окружении. Такой подход способствует реализации
проекта, но в долгосрочном плане маловероятно, чтобы он породил какие-либо изменения в
поведении, которые могли бы повлиять на аспекты управления изменениями персонала.
2. Заинтересованность и методы совместного решения проблем. При таком подходе от-
ношения строятся и поддерживаются так, что это способствует постоянству происходящих
изменений в групповом и индивидуальном поведении, что более располагает к культурным
изменениям.
Обе методики нужно применять для обеспечения значительных организационных изме-
нений, которые необходимы для проектов BPM. В небольших или крупных проектах при не-
значительном влиянии культурных изменений главным подходом будет управление взаимо-
действием для успешной реализации.
Тема управления отношениями с заинтересованными сторонами (и подробное изложе-
ние теорий и этих методик) слишком широка для обсуждения в этой книге. Мы дадим лишь
сжатую сводку практического управления отношениями с заинтересованными сторонами
для применения этих методик в проекте BPM.
Управление отношениями для успешной реализации. Шаги методики следующие:
1. сформировать внутреннюю группу для разработки формата, плана и осуществления
управления отношениями с заинтересованными сторонами и их привлечения к участию в
проекте.
2. Определить все заинтересованные стороны и их отношения с проектом.
3. Очертить роль в проекте основных заинтересованных сторон.
4. Сопоставить заинтересованные стороны, чтобы выявить их индивидуальные требова-
ния или результаты, которые им нужны от проекта.
5. Определить лучшие стратегии привлечения каждой заинтересованной стороны и
управления отношениями с ней, чтобы удовлетворить их запросы и обеспечить надежность
реализации проекта.
Далее каждый из этих шагов рассматривается более подробно.
Шаг 1. Формирование внутренней группы заинтересованных сторон
На этом шаге важно, чтобы менеджер проекта привлек бизнес-представителей и обеспе-
чил их полноценное участие в формировании формата отношений с заинтересованными сто-
ронами, а также обеспечил подробное планирование, привлечение в проект и выполнение.
Кого из бизнеса нужно привлечь? Обычно это хозяин бизнес-проекта, спонсор проекта и
все прочие заинтересованные лица, которые консультировали или предложили окончатель-
ное решение.
Менеджер проекта и глава заинтересованных лиц несут ответственность за управление
отношениями с заинтересованными сторонами и:
 пользуются высоким уважением руководителей во всей организации;
 пользуются доверием во всей организации;
 свободно высказывают свое мнение, даже если оно идет вопреки культуре организа-
ции;
 могут облекать плохие и хорошие новости в адекватную, но честную форму;
 считаются поборниками и главными действующими лицами изменений в организа-
ции;
 способны обеспечить выполнение заданий.
Одна из задач менеджера проекта — «продвижение» заинтересованных лиц на позиции,
нужные для поддержки проекта, и управление и контроль отношений с заинтересованными
сторонами. Менеджер проекта должен быть уверен в поддержке и помощи спонсора проекта,
а также в возможности доверительно обсуждать вопросы отношений с заинтересованными
сторонами.
Менеджер проекта должен подсказать членам группы проекта, что нужно донести до
конкретных заинтересованных лиц, чтобы заручиться их поддержкой. Эти посылы должны
согласованно доносить все члены группы проекта.
Менеджер проекта распределяет поручения среди других основных членов группы про-
екта и бизнес-группы. Эти задания рассматриваются на последующих шагах.
 Шаг 2. Определение всех заинтересованных сторон и их отношений к проекту
Нужно составить подробный перечень заинтересованных сторон. В качестве основы для
него можно взять перечень заинтересованных сторон, составленный на шаге 4 этапа стар-
товой площадки. Типовой перечень выявленных на этом шаге заинтересованных сторон не-
большого проекта BPM включает:
Внутренние Внешние

Сотрудники-персонал Посредники

Руководство Клиенты

Финансовое подразделение Менеджеры фондов

Подразделение управления объектами Внешние аудиторы

Подразделение соблюдения нормативов Поставщики решений

Подразделение управления рисками Законодательные органы

Подразделение информационных техноло- Партнеры

гий

Внутренние аудиторы

Подразделение развития бизнеса

Как видно из этого ориентировочного перечня, возможно, придется управлять отноше-

ниями со многими заинтересованными сторонами. Вероятно, у вас не будет хватать времени
на всех, и нецелесообразно управлять отношениями со всеми. Выше перечислены группы
заинтересованных сторон, и нужно в каждой группе выделить лиц, являющихся важными
заинтересованными лицами. Группа проекта должна понимать, что персонал организации —
это одна из важнейших заинтересованных сторон, и без его поддержки и энтузиазма про-
ект либо закончится неудачей, либо столкнется с серьезными проблемами. В главе 25 эта
сторона вопроса рассматривается подробнее.
Чтобы определить, отношениями с какими заинтересованными лицами нужно управ-
лять, менеджеру проекта и главе заинтересованных сторон следует заполнить одну из мат-
риц шага 3, а лучше обе. Они помогут выделить заинтересованные стороны, управление от-
ношениями с которыми целесообразно. При необходимости обновляйте эти матрицы после
каждого совещания с участием заинтересованных сторон.
Шаг 3. Формулирование роли ключевых заинтересованных сторон в проекте
После определения заинтересованных сторон менеджеру проекта нужно составить опи-
сание каждой из них. Для каждого основного заинтересованного лица удобно воспользо-
ваться формой из табл. 24.2. Индивидуальный анализ заинтересованного лица должен быть
рассмотрен менеджером проекта и/или главой заинтересованных сторон до личной встречи,
чтобы решить, чего проект намерен добиться с его помощью.
Таблица 24.2 Анализ индивидуального заинтересованного лица
ФИО / Название Должность
Возможность влияния на проект (выде- Видение проекта (выделите нужную оценку на
лите нужную оценку на линии) линии)
сильно слабо положительно отрицательно
риски Какие риски привносит заинтересованное лицо
Сильные стороны Какие сильные факторы привносит заинтересованное лицо
Слабости Какие слабости связаны с заинтересованным лицом
В чем интерес в Что «заводит» / вызывает пропадание интереса (что нравится / не нра-
проекте заинтере- вится заинтересованному лицу в проекте, его роль, организация, личные
сованного лица интересы и т.д.)
 Ниже даются краткие пояснение столбцов в табл. 24.2 (если они не очевидны).
Возможности сегодня и после реализации проекта. Источник относится к должности,
личным качествам (напористость, обаяние), знаниям или умениям (зрелость) в области BPM,
контролю ресурсов (возможность выделять или отбирать ресурсы под проект), наличием
права вето на проект. Относительное влияние можно просто отнести к сильному, среднему
или слабому.
Способность влиять на проект и другие заинтересованные стороны: есть необходи-
мость понять, насколько сильно влияние или широки возможности данного заинтересован-
ного лица в отношении проекта и других заинтересованных сторон. Кто на кого может вли-
ять, и как это достигается? Будет ли меняться реакция заинтересованных сторон по мере ре-
ализации проекта, и каким образом? В главе 25 упоминаются контролеры изменений. Это
люди, которые потенциально фильтруют информацию, перед тем как она поступает другим
заинтересованным лицам или группам. Нужно понять, является ли данное заинтересованное
лицо контролером, и если да, как оно будет себя вести и, возможно, отфильтровывать ин-
формацию перед пропуском далее. Нужно также понять, как это может (или будет) влиять на
проект.
Видение проекта (уровень заинтересованности): не все заинтересованные лица пред-
ставляют себе результаты проекта или заинтересованы в них; некоторых интересует лишь
происходящее в ходе реализации проекта. Но нужно всегда быть начеку и искать новых за-
интересованных лиц. Нужно как можно раньше обнаружить их и управлять отношениями с
ними.
Зачем мне это? Важнейший аспект, в котором нужно разобраться. Как можно направ-
лять обмен информацией и контролировать результаты, если вы не понимаете, в чем интерес
конкретного заинтересованного лица? Здесь речь идет не только о воздействии непосред-
ственных результатов проекта, но и об их влиянии на будущее заинтересованного лица в
личном и профессиональном плане.
Чтобы выявить основных заинтересованных лиц и облегчить их сопоставление, часто
полезно отразить более подробную информацию в матрице, приведенной в табл. 24.3. Не по-
думайте, что из порядка изложения следует, что одна из матриц заполняется раньше другой.
Часто их заполняют параллельно и постоянно обновляют по ходу проекта.
В табл. 24.3 приведены аналогичные сводные данные по всем выявленным заинтересо-
ванным сторонам.
Таблица 24.3 Матрица анализа заинтересованных лиц
Ти ФИО / Возможность влияния Способность Видение проекта Зачем
п Назва- сегодня После реализации про- влиять на про- (степень заинте- мне
ние екта ект и другие ресованности) это
источ- относитель- источ- относитель- заинтересован- нуж-
ник ная власть ник ная власть ные стороны но?

Первый шаг в заполнении этой матрицы — классификация заинтересованных сторон по

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

Кейс: в результате проекта заинтересованное лицо лишилось своей роли

Мы начали проект с обычного этапа стартовой площадки. К моменту составления от-
чета этапа инноваций серьезной рекомендацией была реорганизация структуры одного от-
дела:
 сокращение численности наполовину,
 сокращение количества менеджеров с пяти (один старший плюс четыре младших) до
одного на весь отдел
Спонсором проекта был менеджер этого отдела, так что проект мог бы закончиться тем,
что он лишился бы своего места в организации. Без деликатного и внимательного управле-
ния отношениями с заинтересованными лицами это могло бы вызывать щекотливую ситуа-
цию.
 Вывод. Проведите анализ заинтересованных лиц и поймите эффект воздействия на ос-
новных из них, подходите к этому вопросу деликатно и внимательно.
Прогнозирование результатов — это часть анализа и управления отношениями с заинте-
ресованными сторонами. Вероятное воздействие нужно оценивать постоянно по всему ходу
проекта.
Мы отдаем себе отчет, что какую-то информацию будет трудно получить, какая-то будет
субъективна, конфиденциальна и деликатна. Насколько открыто менеджер проекта может
распоряжаться этой информацией, будет определяться культурой и зрелостью организации и
отдельных заинтересованных лиц.
В некоторых странах складывается тенденция значительной открытости отношений с
заинтересованными сторонами и их позиции в отношении проекта. Такое поведение основа-
но на понимании, что управление отношениями с заинтересованными сторонами — это не
манипулирование, а оказание открытого честного влияния на них, в котором раскрываются и
учитываются интересы заинтересованных сторон. Такой подход формирует доверие.
Но открытость не всегда возможна в силу уровня зрелости организации и отдельных
заинтересованных лиц. Нужно проявлять высшую степень осторожности при хранении
этой информации в документации проекта и предоставлении доступа к ней.
Шаг 4. Сопоставление заинтересованных сторон
Собрав информацию, можно сделать следующий шаг — разнести заинтересованных лиц по
двум отдельным матрицам, которые покажут тонкие различия между ними и дадут возмож-
ность принять решения о подходе к заинтересованным сторонам. Цель сопоставления — по-
нять положение заинтересованных сторон на текущий момент и положение, которое они
должны занимать с точки зрения проекта.
Первая матрица (анализ видения и влияния на проект заинтересованных лиц, рис. 24.2)
показывает менеджеру проекта возможности заинтересованного лица влиять на проект и его
видение проекта.

Ось «влияние на проект» относится к власти, которой заинтересованное лицо может об-
ладать в проекте. У него может быть право вето или утверждения проекта. Заинтересован-
ные лица могут также открыто или неявно обладать значительной властью и влиянием на
проект при его запуске, в ходе реализации и на этапе внедрения.
Ось влияния сочетается с осью «видение проекта». Заинтересованные стороны могут
иметь жизненный интерес в проекте, поскольку он положительно или отрицательно скажет-
ся на их способности удовлетворить бизнес-нужды и личные запросы; но могут вообще не
иметь интереса в проекте. Менеджеру важно понимать, что «видение» проекта отдельными
заинтересованными лицами может появиться в ходе проекта, по мере осознания влияния
проекта на них самих. Такое видение возникает в результате взаимодействия менеджера
проекта с заинтересованными лицами или приобретения полезной информации. В любом
случае менеджер проекта должен заметить это, переосмыслить и держать под контролем.
Круги на рис. 24.2 и 24.3 представляют текущее положение отдельного заинтересованно-
го лица, а стрелки указывают положение, куда нужно его переместить. Кружки без стрелок
означают, что заинтересованное лицо находится в положении, которое менеджер проекта
считает правильным, и поэтому данное лицо перемещать не требуется. Как видно из рис.
24.2, одно из заинтересованных лиц имеет возможность оказывать слабое влияние на проект
и отрицательно относится к нему. Менеджер проекта решил, что это важное заинтересован-
ное лицо, и его нужно переместить из текущего положения в положение с положительным
видением проекта и возможностью оказывать сильное влияние на него. Чтобы добиться это-
го, нужно предпринять ряд действий.

Хотя рис. 24.3 очень похож на рис. 24.2, есть тонкие различия, которые нужно выделить
и изучить.
У заинтересованного лица может не быть твердой убежденности в проекте, но быть
очень высоким энтузиазм. Энтузиазм заинтересованного лица может сочетаться с нестыков-
кой с его личными или бизнес-целями, вызывая убежденность «против» проекта (эффект ор-
ганизационной «солянки» — неупорядоченной мешанины систем, приложений, интересов,
людей и т.д.).
Если должно произойти перемещение заинтересованного лица, менеджеру проекта по-
надобится разработать стратегию для каждой стрелки на этих двух рисунках. Такая страте-
гия является комплексом мер, осуществление которых должно обеспечить переход заинтере-
сованного лица на нужную клетку в матрице. И здесь мы подошли к последнему шагу
накопления информации о заинтересованных сторонах перед планированием стратегии вза-
имодействия с ними. Нужно:
 документально оформить результаты, которые хочет видеть в проекте каждая заинте-
ресованная сторона,
 сопоставить их с фактическими целями и задачами проекта.
Тогда будет видна синергия целей или ее отсутствие.
Шаг 5. Определение наилучшей стратегии вовлечения, взаимодействия и управле-
ния отношениями с заинтересованными сторонами
Это последний шаг управления отношениями с заинтересованными сторонами, который
состоит в разработке стратегического плана (пути) успешного вовлечения в проект заинтере-
сованных сторон.
План нужно составить на общем проектном уровне и на уровне отдельных заинтересо-
ванных сторон; он должен обеспечить путь от целей и задач отдельного заинтересованного
лица к целям и задачам проекта. В нем должно быть видно, как менеджер проекта намерен
работать с заинтересованными лицами, которые «за» проект, и с теми, кто «против», как он
будет «зажигать» тех, кто скептически настроен к проекту, чтобы они воспринимали его с
энтузиазмом (или хотя бы нейтрально).
План должен показывать:
 как заинтересованное лицо оценивает эффективность реализации проекта;
 какое положение должно занимать заинтересованное лицо, чтобы способствовать
успешной реализации проекта;
  как менеджер проекта будет продвигать интересы заинтересованных лиц, используя
выявленные движущие мотивы, чтобы они помогали правильной реализации проекта;
 периоды изучения — должны происходить при каждой встрече менеджера проекта с
заинтересованным лицом, на формальном совещании или в коридоре.
Данная стадия должна увязываться с планом общения/обмена информацией, разрабо-
танным как часть проекта, а также с аспектами, рассматриваемыми в главе 26.
Управление отношениями с заинтересованными сторонами на основе учета интересов
Отношения с заинтересованными сторонами при реализации проекта могут вызывать
эффект отторжения, который не только наносит ущерб взаимоотношениям, но и влечет лишь
краткосрочные изменения в поведении. Так что сразу по окончании проекта поведение воз-
вращается к предыдущим моделям и обычаям, и потенциальные выгоды для организации
могут быть утрачены. Если у вас именно такой случай, важно применить другие методы
поддержания отношений при подъемах и спадах по ходу реализации проекта и обеспечения
постоянства и закрепления изменений в результате проекта. Лучше всего этого достичь,
применяя основанный на интересах подход к управлению отношениями с заинтересованны-
ми лицами, что включает методы совместного решения проблем. Такое управление показано
на рис. 24.4.

Управление отношениями с заинтересованными сторонами на основе интересов предпо-

лагает:
 оценку проблем, определение вопросов и создание условий для решений, от которых
выигрывают все, — это необходимо сделать до выяснения индивидуальных коренных инте-
ресов:
 выяснение основополагающих интересов, т.е. интересов, которые предопределяют
занимаемую людьми позицию;
 анализ любых зон разногласий с использованием приемов типа мозгового штурма для
выработки решений, устраивающих всех. Один из методов договориться — BATNA (каждый
предлагает свое видение лучшей альтернативы обсуждаемому решению вопроса). Это поз-
воляет определить пределы договоренности и снижает вероятность занятия позиции «глухой
обороны» в ущерб остальным сторонам.
Шаги, необходимые для совместного решения проблем [80]:
 выявить основополагающие интересы в связи с потребностями, желаниями, заботами
и опасениями; это достигается пониманием того, почему вы занимаете определенную пози-
цию в конфликте;
 изучить все интересы, в том числе используя прием эмпатии («поставь себя на место
оппонента»);
  активно слушать, используя такие приемы, как соблюдение очередности выступле-
ний, применение мимики и жестов, выражающих полное внимание, открытое поведение;
 отделять людей от проблемы;
 использовать мозговой штурм;
 находить новые творческие альтернативы;
 оценить, обеспечивает ли решение проблемы разрешение всех основных вопросов.
Многостороннее управление отношениями с заинтересованными сторонами на основе
учета интересов
Принципы, используемые при совместном решении проблем между двумя сторонами,
можно применить и в случае решения проблем между несколькими сторонами в организа-
ции. Помимо индивидуальных отношений, процесс разрешения проблем должен учитывать
организационную структуру и иметь дело с коалициями, фракциями и альянсами заинтере-
сованных лиц. Принцип все тот же — поиск выигрышного для всех решения, разрешающего
основополагающие вопросы.
Пример этого описан у Грея (Gray) [21], где разъясняется «кооперативный» подход к
многостороннему разрешению конфликтов. Этот подход направлен на изучение различий
между заинтересованными сторонами по конкретному вопросу, чтобы выработать новые
решения проблемы. Среди прочего для применения такого кооперативного подхода к разре-
шению конфликтов нужно:
 определить проблему;
 твердо настроиться решить проблему;
 выявить все заинтересованные стороны, затронутые проблемой;
 оценить интересы затронутых сторон;
 определить имеющиеся для решения проблемы ресурсы;
 установить основные правила игры;
 определить основные действия;
 организовать подгруппы, работающие по решению проблем;
 обмениваться информацией;
 изучить различные варианты;
 достичь согласия с другими заинтересованными сторонами;
 реализовать соглашение.
Привлечение третьей стороны предусматривает посредничество, примирение, арбит-
раж и принятие решения. Такие подходы являются комбинацией противоборствующего и
кооперативного подходов к управлению отношениями и привлекают третью сторону в каче-
стве особой силы с целью направить стороны к соглашению или урегулированию. Для при-
менения этих методов нужно:
 знать, когда привлечь третью сторону в процесс разрешения конфликта;
 четко определить роль третьей силы;
 согласовать процесс разрешения конфликта в рамках этих подходов;
 договориться об окончательном результате процесса урегулирования.
Применение на практике. Управление отношениями с заинтересованными сторонами в
проекте часто осуществляется на интуитивной, а не на формальной основе. Хотя менеджер
проекта часто говорит о необходимости управления отношениями и посвящает много време-
ни этой части управления проектом, она очень редко систематически анализируется, плани-
руется и осуществляется, а ведь взаимоотношения — основа всего, что мы делаем.
Важнейшие аспекты управления отношениями с заинтересованными сторонами:
 понимание, кто эти заинтересованные стороны/лица;
 понимание их связи с проектом и друг с другом;
 определение роли, которую они играют или будут играть в проекте;
 определение их требований к проекту;
 определение наилучшего способа их привлечения, чтобы удовлетворить их запросы.
Прекрасно, если спонсор и хозяин бизнес-процесса участвуют в процессах планирования
отношений, взаимодействия сторон и реализации планов и активно поддерживают эти про-
цессы.
Менеджеру проекта и спонсору важно осознавать, что управление отношениями — это
работа с людьми, поэтому результаты не гарантированы. Менеджер может организовать
управление отношениями по самым высоким стандартам, и все же не получить нужного ре-
зультата либо из-за того, что заинтересованные стороны подали неверный сигнал (намерен-
но или неумышленно), либо из-за того, что они просто передумали.
Риски проектного управления. В этой значимой части проекта заложены определенные
риски, которые необходимо устранять их или хотя бы снижать. Некоторые из рисков указа-
ны в табл. 24.4.
Таблица 24.4. Риски управления проектом и стратегии их снижения
Риск Стратегия снижения

1. не все шлюзы определены и На этапе стартовой площадки и по ходу остальных этапов проекта
контролируются необходимо выявлять и контролировать возможные «шлюзы» как мож-
но раньше. Если шлюз не пройден успешно, проект следует завершить
или приостановить

2. не проведен тщательный Обеспечьте включение шагов управления отношениями с заинтересо-

анализ заинтересованных сторон ванными лицами в план проекта при постоянном упреждающем внима-
нии к ним по ходу проекта

3. не ведется полноценное Работа по BPM критически важна для бизнеса и несет потенциально
управление отношениями с ними существенный риск. Бизнес-менеджер проекта не является бизнес-
экспертом, но должен иметь значительный опыт как управления проек-
тами, так и BPM

4. не назначен бизнес- Обеспечьте наличие в проекте как специалиста по управлению проек-

менеджер проекта тами BPM, так и аналитика процессов

Глава 25. Управление изменениями персонала

Хорошие компании быстро реагируют на перемены;
Лучшие компании создают перемены.
Будьте на шаг впереди; изменяйтесь до того, как это сделать придется.
Хригель, Брандт (Hriegel, Brandt) [35]
… преобразование корпорации — не просто мечта, а острая необходимость.
Кин (Kin) [38]
В бизнесе нет везения. Если бизнес постоянно меняется, должен целенаправленно при-
меняться процесс, который подсказывает, куда нужно двигаться. Нужно понимать, чего
вы стремитесь достичь, и быть уверенным, что делаете это правильно.
Дон Аргус (Don Argus), бывший председатель правления Нацбанка Австралии [6]
Компании в ранге от хороших до лучших обращали мало внимания на управление изме-
нениями персонала, мотивирование людей или формирование взаимосвязей. В правильных
условиях проблемы настроя, мотивации и изменений сходили на нет.
Джим Коллинз (Jim Collins, 2001)
Интересное выражение в этой фразе — «в правильных условиях». Создание «правильных
условий» — задача руководителей — лидеров организации, и случайно это не происходит.
Как сказал Дон Аргус «…должен целенаправленно применяться процесс». Вот почему
управление изменениями персонала — один из трех неотъемлемых атрибутов проекта BPM
(рис. 25.1). Это процесс применения запланированных в проекте изменений персонала.
 За исключением совсем уж небольших или изолированных проектов, в ходе проекта
BPM необходимо работать с культурой, особенно на этапе работы с персоналом. Но нужно
проявлять осторожность и не давать возможность отдельным работникам использовать
культуру как предлог для сопротивления изменениям, утверждая, что «здесь так принято ра-
ботать» или «так здесь сложилось».
Если культуру нужно улучшать, это всегда следствие того, что:
 какая-то часть процессов, структуры или систем управления персоналом (включая
руководителей) работает не совсем правильно;
 ошибочны ролевые инструкции или нормативы показателей эффективности;
 недостаточно отлажена управленческая отчетность или структура;
 не хватает умений или штатов;
 неверен стиль руководства или результат воздействия внешних сил, вынуждающих
изменять процессы в организации;
 отсутствует необходимая реакция или изменения структуры или систем управления
персоналом.
Проблемы обычно являются коренными причинами, культура — результатом.
В проекте BPM следует всегда иметь в виду, что результат проекта — это его цель и
задачи, а любое необходимое изменение культуры — результат цели и задач проекта. Не-
которые культурные изменения оказываются непременным условием успеха проекта, но
они не являются самоцелью.
В этой главе рассматривается важность процесса изменений в конкретном разрезе внед-
рения проекта BPM. Суть проектов BPM — в изменении процессов и способов ведения биз-
неса в организации, и если подумать, изменение в культуре — «просто еще один процесс».
Изучим этот «процесс», методы его реализации, и самое главное, его поддержку с течением
времени.
Управление изменениями персонала — базовый атрибут успешного проекта BPM и об-
ласть, на которой должно быть сосредоточено внимание в течение всего проекта. Обычно
невозможно заранее определить все шаги и проблемы в программе изменения, поэтому
очень важно иметь четкий механизм ведения проекта в этом процессе. Пример такого меха-
низма приведен на рис. 25.2.

Изменения носят личностный характер … Жесткое лидерство дает лишь ограничен-

ные результаты. Переход от бюрократии к гибким самоуправляемым группам требует
психологической готовности многих менеджеров и рядовых работников.
Fortune, 27 августа 1994 года
Эта глава посвящена организации процесса, помогающего «рядовым менеджерам и ра-
ботникам» подготовиться к переменам и принять их.
Шаг общения/обмена информацией не выделяется отдельно, но к нему мы обращаемся
на различных шагах, особенно на шаге 3.
Шаг 1. Сопротивление переменам
Марку Твену приписывают фразу, что «единственный человек, который желает смены,
— это обмочившееся дитя». Знаете, возможно, это так. Если Марк Твен прав, то почему лю-
ди так не любят перемены? Вот некоторые причины:
1. страх - самая распространенная, и одна из наиболее серьезных причин сопротивле-
ния. Часто она связана с неопределенностью, непредсказуемостью, неудобством и беззащит-
ностью перед переменами. Сильные средства преодоления фактора страха — общение и
честность.
2. Ощущение бессилия. Часто возникает тогда, когда группа проекта и руководители
бизнеса недостаточно плотно вовлекают людей. Дайте людям возможность участвовать в
делах и чувствовать, что они могут влиять на процесс перемен.
3. Очень много сил и мук. Часто осуществление изменений требует много усилий и даже
мук, и только потом к ним привыкают. Большинство людей стремятся избежать трудностей
и получить удовольствие, а в данном случае, удовольствие означает статус-кво.
4. Отсутствие личного интереса. Люди должны понять и осознать последствия пере-
мен. Если они отрицательные, вас спросят: «Зачем что-то менять?», и тогда нужно препод-
нести четкую аргументацию. На шаге 2 поясняется, для чего люди должны понимать необ-
ходимость перемен.
Следует предвидеть, насколько возможно сопротивление, проводя исследования с по-
мощью опросов и анкетирования. В проекте должно сформироваться понимание типов и
уровня изменений. Спонсор проекта и группа проекта должны осознавать, что часто сопро-
тивление нарастает к концу проекта, по мере расширения объема имеющейся информации.
Необходимо предусмотреть, как справиться с ростом сопротивления.
Шаг 2. Необходимость изменений и роль лидеров на рисунке Зачем меняться? Роль
лидеров-руководителей – С.К.
В традиционных проектах реинжиниринга бизнес-процессов (BPR) «в фокусе — работа
над процессами, новыми технологиями и децентрализацией сервисов, а не люди, которым
придется реализовать перемены»
(Голдсмит — Goldsmith, [20]).
«Легко выдвинуть идею, трудно ее реализовать. Реформы гибнут в окопах, а кто сидит в
окопах? Люди». «Самая озадачивающая, раздражающая, расстраивающая и непонятная часть
BPR — это люди» [26].
Майкл Хаммер (Michael Hammer), 1993 г.

Раздражают люди или расстраивают, не так важно. Факт в том, что люди являются ре-
шающим фактором успеха любого проекта BPM, и если не выстроить эту часть проекта пра-
вильно, он либо провалится, либо его успех будет ограничен. Группа проекта может вырабо-
тать лучшие процессы и системы BPM, но если люди откажутся применять их или будут
пользоваться ими неправильно, проект не будет успешен.
Роль лидеров более подробно рассмотрена в главе 26, но здесь важно отметить место,
которое должны занимать лидеры в мероприятиях по управлению изменениями персонала.
Люди не любят перемен, и не станут осуществлять программу изменений или участво-
вать в ней, если не поверят, что это необходимо. Упрощенно, есть два способа убедить лю-
дей меняться. Выбранный подход зависит от конкретной организации, обстоятельств и стиля
руководства лидера.
Кейс: внедрение рабочего потока и системы электронных документов
Мы работали с одной чрезвычайно консервативной организацией. Помогая в разработке
обоснования для внедрения систем рабочего потока и электронного копирования докумен-
тов, мы услышали, что это не будет работать!
Когда мы спросили, почему, нам объяснили, что организация пыталась внедрить их лет
пять назад, и ничего не вышло, поэтому руководители нервничали из-за второй попытки.
Дальнейшее исследование показало, что проект не предусматривал никакого управления из-
менениями персонала.
Персонал организации чрезвычайно опасался новой системы, и когда ее внедрили, про-
сто отказался пользоваться ею. Руководство фактически демонтировало систему и верну-
лось к старым затратным в работе ручным процессам.
Вывод. Если вы рассчитываете на изменение в поведении людей, их надо выслушивать
и привлекать к планированию процесса изменения.
Первый способ:
Считается, что должен произойти кризис, задача руководителя — определить мас-
штаб, остроту и последствия кризиса и донести это до людей. В равной степени важно,
чтобы руководитель также был способен указать пути преодоления кризиса — сформули-
ровать и разъяснить новую стратегию, новую модель компании, новую культуру.
 Герстнер (Gerstner) [19]
При разъяснении критической ситуации или причин перемен абсолютно необходимо,
чтобы руководитель формально заявил людям, что «отсутствие перемен полностью исклю-
чается», чтобы они осознали, что программа перемен неизбежна, и решили, как и когда
включатся в нее. Если кризис существует, открытость, честность и поддержание моральной
чистоты играют важную роль в разъяснении кризиса и продвижении вперед. Если «кризис»
спровоцирован специально, чтобы инициировать перемены, потенциально есть возможность
конфликта с необходимой честностью и моральной чистотой, требуемой от лидеров.
Второй способ более изощрен, и от руководителей требуется донести до людей суще-
ствование некой «проблемы», разъяснить ее масштаб и необходимость перемен. Люди
должны понять для себя и организации последствия того, что проблемы «не будет решена».
Людям не нужны уговоры: им нужно лидерство — направление движения, постоянство,
импульс и настойчивость. Сотрудникам нужны лидеры, которые нацелены на решения и
действия. Если придется принимать жесткие решения, как часто бывает в любой программе
изменений, примите их как можно раньше и донесите до всех руководителей, сотрудников и
заинтересованных лиц, объяснив, почему это необходимо, а затем реализовывайте.
«Реализовать реинжиниринг — это развести костер на голове и тушить его молотком:
больно и надоедает».
Неизвестный
Высшему руководителю не нужно, да и не следует возглавлять все программы измене-
ний персонала. У них должен быть спонсор или лидер, который будет направлять процесс
перемен, особенно в случае сценария «пилотного проекта» или «вне поля зрения». Роль та-
кого лидера будет заключаться в том, чтобы дать ответы на следующие вопросы, всегда
оставаясь в рамках проекта:
 чего должны достичь изменения?
 Почему изменения необходимы?
 Каковы последствия этих изменений, как для организации, так и для отдельных лиц
[66]?
Последнее подразумевает не только итоги процесса перемен, но и события, которые
произойдут, если не вносить изменений.
Изменения требуют времени и упорства руководителей на всех уровнях организации и
группы проекта. Нельзя, чтобы их возглавлял только высший руководитель. Три предлагае-
мых уровня «лидерства» описаны в главе 26.
Когда руководители инициируют процесс общения для объяснения и мотивирования
людей на изменения, они должны указать путь вперед — «реалию» ситуации. Но, преподно-
ся факты и объясняя их, нужно говорить правду.
Если руководители говорят, что у них на это нет времени, они должны понять, что это
— их работа! Они сами должны измениться первыми и стать ролевой моделью для осталь-
ной организации.
Хотя в задачу лидеров не входит разработка детального плана шагов по управлению из-
менениями персонала, они должны обеспечить ответственность менеджера проекта, который
совместно со спонсором проекта, руководством организации и отделом кадров предусмотрят
все шаги по разработке и реализации такого плана.
Лидеры, а в данном контексте мы имеем в виду любого, кто служит образцом для дру-
гих, должны понимать, что люди разные, и им требуется разное время и усилия для измене-
ний. Некоторые изменятся быстрее, другие — медленнее, а кто-то так и не изменится, и с
ними нужно обойтись достойно. Задача лидеров — понимать это и предоставлять людям до-
статочно времени и поддержку.
Успешные программы перемен сочетали три важных качества:
1. увлеченность,
2. энтузиазм и
3. остроту переживаний.
Задача лидера — «зажечь» каждое это качество и поддерживать «горение».
Важнейшим элементом здесь (и итогом любой программы управления изменениями
персонала) является «общение в квадрате» — с общением перестараться невозможно. Это
поясняется на шаге 3 (компоненты программы перемен).
Шаг 3. Компоненты программы перемен
 Перед тем как приступить к пояснению компонентов программы перемен, важно четко
затвердить, что обязанность комитета по руководству проектом BPM (а также менеджера и
бизнес-спонсора) — обеспечение результативности этой программы. Ее нельзя перепоручить
или полностью (или частично) делегировать кому-либо, например:
1. Другому подразделению. Иногда может возникнуть соблазн перепоручить это отделу
кадров. Хотя нет сомнений, что отдел кадров должен быть глубоко вовлечен в программу,
координация работы такова, что менеджеру проекта приходится привлекать все аспекты
проекта BPM: например, этап работы с персоналом окажет значительное влияние и даст
наработки для программы управления изменениями персонала.
2. Консультантам. Это чисто внутренняя работа, которую нельзя передать никакой
внешней группе. Разумеется, консультанты могут подсказывать идеи, структуры и делиться
накопленным опытом, но ответственность за планирование, выполнение и достижение ре-
зультатов должна лежать на менеджере проекта и бизнесе.
Мы предлагаем следующие важнейшие компоненты программы перемен:
1. Разработка детального проектного плана.
2. Выбор основного персонала, привлекаемого к программе.
3. Четкое понимание привязки программы к стратегии, культуре, структуре, новым ро-
лям, новым процессам и всему проекту BPM.
4. Детальный план общения/информирования, описывающий способы доведения ин-
формации до всех заинтересованных лиц.
Мы остановимся на каждом компоненте и кратко опишем его роль в программе перемен
и важнейшие моменты, требующие учета.
Планирование. Программа управления изменениями персонала может сама по себе
предполагать значительные усилия и содержать различные действия и мероприятия, которые
нужно интегрировать и встроить в общий план проекта. В план, разумеется, необходимо
включить все шаги, включенные в программу перемен, распределение ответственности и
сдаточные стадии. Она должна содержать особо разработанные шаги, показывающие, как
организация или бизнес-подразделение намерены «разморозить», переместить и закрепить
организацию. Разморозить в данном случае означает формирование осознания и необходи-
мости перемен и среды, восприимчивой к переменам. Переместить — сосредоточиться на
изменении сил и смене поведения со старого на новое. Закрепить — процесс «схватывания»,
который ведет к структуризации перемен, делая их устойчивыми и превращая в часть повсе-
дневной работы [41].
Теперь необходимо ответить на ключевые вопросы: кто, что, на что и как? Вот примеры
таких вопросов:
1. Кто будет привлечен к программе перемен: клиенты, поставщики, инвесторы, руко-
водство, сотрудники внутри организации (по всей организации или локально, в одном или
нескольких подразделениях)? Конечно, это будет зависеть от выбранного сценария проекта
BPM.
2. Что будет меняться, какая новая информация потребуется или будет выработана?
3. На какие новые ощутимые результаты или итоги можно рассчитывать?
4. Как изменения стыкуются друг с другом и воздействуют на новое ожидаемое состоя-
ние организации?
На эти вопросы следует ответить до завершения процесса планирования.
Выбор основного персонала. Имеется в виду выбор активных сторонников перемен —
членов организации, которые станут лидерами программы перемен. Они должны находиться
на всех уровнях в организации и в группе проекта. В главе 26 рассмотрено три уровня ли-
дерства, и такие активные сотрудники, поддерживающие изменения, должны тщательно от-
бираться со всех этих уровней.
Понимание взаимосвязей. На программу перемен будут влиять все этапы и аспекты про-
екта BPM, а сама программа будет влиять на них. Такие взаимосвязи постоянно указывались
в этой книге, но мы назовем следующие:
 стратегия организации;
 культура организации;
 любая новая предлагаемая структура организации, роли-должности сотрудников и
процессы.
 Как уже говорилось выше, эти взаимосвязи показывают, почему управление изменения-
ми персонала фигурирует как неотъемлемый атрибут общей схемы, а не ее этап.
План общения/обмена информацией. Стратегия общения и план являются важнейшим
аспектом любой программы перемен. Их нужно тщательно продумать и постоянно коррек-
тировать по ходу всего срока действия по мере получения новых данных и понимания, что
работает хорошо, а что могло бы работать лучше.
Ниже дается сводка общих указаний, разъясняющих, как подходить к выработке плана
общения/обмена информацией и какие вопросы должны в нем решаться [66].
 Подготовка
 Сегментация аудитории или различных групп, которым будут адресованы посылы.
1. План использования различных каналов для донесения посылов, обеспечивающий
применение всех приемов и средств персонального общения: визуальных, слуховых и кине-
тических.
2. Посылы должны доноситься многими людьми — у разных людей разные стили об-
щения; но нужно обеспечить согласованность посылов, чтобы они не были противоречивы-
ми.
3. Будьте понятны, передавайте простые посылы, сделайте так, чтобы ожидания всегда
задавались программой перемен, никогда не оставляйте формирование ожиданий на усмот-
рение получателей посылов.
4. Для всей программы должно быть небольшое количество простых основных посылов.
Люди не запомнят и не станут слушать большое количество сложных обоснований. Чем вы-
ше ранг руководителя, тем проще и понятней должны быть посылы.
5. Честность — единственная политика. Рано или поздно истина все равно выйдет
наружу, и тогда программа и ее исполнители могут утратить всякое доверие, если не при-
держивались честного подхода.
6. Игра на человеческих эмоциях; одна только логика не воспринимается и не сработает.
7. Подчеркивайте и признавайте, что перемены трудны, потому что проблема не столько
в новом состоянии людей, а в мучительности перехода в это новое состояние.
8. Посылы формулируйте проще и нагляднее — скажите людям, как и что конкретно
изменится для них и в их работе (коллективе/подразделении). Изменения должны показы-
вать, как конкретно они подействуют на отдельных людей.
9. Увяжите основные сдаточные стадии плана проекта с мероприятиями по распростра-
нению информации.
10. Самое главное: слушайте, слышьте, прислушивайтесь — делайте выводы и
реагируйте на услышанное.
Сегментация целевых групп заинтересованных лиц позволит нацеливать посылы на от-
дельную аудиторию, отвечая на ее конкретные запросы. Следующие вопросы помогут наце-
лить посылы:
1. какие есть сегменты, кто в них попадает?
1. Как это повлияет на людей? Будьте конкретным и точным.
2. Как отреагируют сотрудники? Важно предвидеть вероятные вопросы, которые будут
заданы, и подготовить ответы на них. Менеджерам нельзя отвечать на вопросы, не имея под-
сказки и ориентировки, поэтому подготовка должна обеспечить согласованность всех посы-
лов в организации, устраняя возможные противоречия и сумятицу.
3. Какое поведение нужно от получателей посылов?
4. Что мы собрались донести до них? Что и как может меняться в зависимости от полу-
чателей посылов. Выбор канала для передачи играет важнейшую роль и может меняться и
приспосабливаться к конкретным сегментам. Каналы донесения посылов могут быть следу-
ющими:
o регулярные бюллетени новостей;
o внутренняя сеть;
o частые новостные сообщения по электронной почте;
o кампания расклейки постеров;
o видео;
o персональные презентации и брифинги;
o информсеансы проекта и программы (встречи без приглашения);
 o практические совещания с людьми для получения обратной связи и совместно-
го решения вопросов;
o сообщения-напоминания на экране ПК.
5. Как мы им скажем?
6. Кто должен им сказать?
Во всех видах общения должен быть сформулирован и согласован единый язык, со стан-
дартными графическими моделями и диаграммами; это будет способствовать единообразию
посылов.
Помните, что нужно твердить: «Общайтесь, общайтесь, и еще больше общайтесь». Но
помните и о законе снижения отдачи. Если новостей нет, не придумывайте ничего только
ради общения.
Шаг 4. Подготовка к изменениям
Упрощенно мероприятия подготовки изменений делятся на две следующие категории:
1. Создание среды/обстановки, которая позволит людям меняться и поощрять измене-
ния.
2. Обеспечение обратной связи о показателях эффективности и программе перемен.
1. Создание среды. Существуют три широкие области, связанные с созданием среды,
позволяющей людям меняться:
 доверие,
 внимание и
 распоряжение судьбой.
Доверие — важнейший фактор. Люди должны чувствовать, что могут доверять своим
лидерам и среде, в которой они действуют, на всех уровнях организации. Они должны ве-
рить, что лидеры ведут себя честно и открыто, их моральные качества высоки, на них можно
положиться. Люди должны знать, что могут задать любой вопрос и получить честный ответ.
В табл. 25.1 приведены примеры действий, которые отвечают и не отвечают этим критериям.
Таблица 25.1. Укрепляющие и разрушающие доверие действия
Укрепляют доверие Разрушают доверие

«Делом подтверждать слова», т.е. позиция и Разговоры, не подкрепленные делами

действия последовательны и соответствуют
сказанным или напечатанным словам

Открытость и честность — нет замены обще- Неправда (если уровень общения низок,
нию, если оно «открытое и честное». Нужно разговоры внутри организации будут по-
прислушиваться к разговорам «в курилке» и рождать слухи и сплетни, которые могут не
учитывать их иметь ничего общего с реальностью).
Насколько важно говорить правду? В 80-х
годах прошлого века компания AT&T по
секрету сообщила аналитикам с Уолл Стрит
о массовых сокращениях. Разумеется, про-
изошла утечка, и некоторые сотрудники
прочитали о грозящих увольнениях в газе-
тах. Работа практически застопорилась, по-
тому что сотрудники боялись за свое буду-
щее. По крайней мере, два работника со-
вершили самоубийство (Fortune, 18 октября
1993). Перемены и правда — вещи очень
серьезные. Правда может ранить, но люди
заслуживают и имеют право ее знать

Говорите «мы» вместо «я» — формируйте Начальник, который получил признание за

командный дух сворованную у работника идею или, наобо-
рот, возлагает вину за свои промахи или
ошибки на других. Ничто не разрушает до-
верие и не деморализует людей быстрее,
чем подобное поведение
Укрепляют доверие Разрушают доверие

Широкое общение убивает слухи Благое дело может утонуть в словоблудии

Внимание означает уважение и сочувствие к другим. Цените вклад людей, их усилия и
благодарите их за это. Уважение включает много факторов укрепления доверия, названных
выше. Люди должны ощущать уважение своих лидеров, когда те всегда говорят правду,
держат свое слово и уважают друг друга.
Распоряжение судьбой означает передачу людям как можно большего контроля над сво-
ей судьбой. Дайте людям информацию, которая позволит им отвечать за свои решения и по-
ступки. Уточните ожидания (чего организация ждет от персонала) и ответственность (какую
ответственность организация ожидает от персонала) — не делегируйте, повышайте уровень
ответственности. Обеспечьте персоналу доступ к информации (сводкам показателей эффек-
тивности) до того, как ее увидит начальник, открывая людям возможность самим внести
корректировки до реакции начальства. Это подводит нас к следующему моменту.
2. Обеспечение обратной связи о показателях эффективности
Руководство не может рассчитывать на изменение сложившегося поведения, пока людям
не обеспечена нормальная рабочая среда (системы и процессы, а также человеческое про-
странство) и не предоставляется информация о качестве их работы с помощью соответству-
ющих систем измерения показателей эффективности, увязанных с вознаграждениями. Это
подробно рассмотрено в главе 18.
Кейс: насколько полезно обучение персонала
В одной организации нам сказали: «Три месяца назад мы обучали персонал в области
обслуживания клиентов и навыков обслуживания по телефону, чтобы повысить уровень сер-
виса, и мало что изменилось».
Мы спросили: «Какие меры были реализованы, чтобы обеспечить обратную связь ра-
ботникам и руководителям об уровне сервиса и телефонных звонках, сообщающих клиентам
о статусе обработки их запросов?» Ответ был: «Мы ведем мониторинг через журнал жалоб
клиентов».
Уже говорилось, что «поскольку делается не то, что вы ожидаете, проверяйте — нужно
придумать способ измерить результаты» (Герстнер, [19]). Совместно с заказчиком мы разра-
ботали комплекс простых показателей эффективности, обеспечивающий мгновенную обрат-
ную связь и меняющий поведение сотрудников.
Вывод. Нельзя рассчитывать на изменения в людях, если у них нет обратной связи с по-
казателями эффективности и привязки достижений нормативов с вознаграждениями.
Шаг 5. Требуемое поведение
Обговорив, зачем и почему нам нужно меняться, почему люди сопротивляются переме-
нам, роль лидеров и руководителей в этом процессе, различные составляющие процесса из-
менений, и как нужно подготовиться к нему, можно спросить: а что же это в точности такое?
Какие поведенческие изменения организация рассчитывает получить и требует от своего
персонала?
Кейс: повышение ранга подразделения по опросу персонала организации
По итогам ежегодного корпоративного опроса персонал не давал положительной оценки
подразделению. Руководитель подразделения попросил нас изучить, почему это произошло,
и добиться повышения оценки подразделения при следующем опросе. Мы провели собесе-
дования с глазу на глаз с 25% персонала с прямыми отчетами и фокус-группами. Мы настоя-
ли на конфиденциальности, и она была обещана персоналу.
Первым шагом было установление базового понимания уровня, на котором подразделе-
ние находилось на тот момент (опрос не давал достаточно сведений), в чем персонал видел
проблемы, и положение, в котором персонал и руководство хотели бы оказаться через два
года. Был разработан путь, состоявший из более тридцати рекомендаций, связанных с дей-
ствиями, которые нужно предпринять для получения желаемого результата.
Вывод. Если не прислушиваться к людям и не включать их в процесс выработки соб-
ственного пути к изменению среды, нельзя ожидать от них увлеченного участия.
В литературе об управлении много разговоров о корпоративной культуре и ее роли в ор-
ганизации. Какой тип культуры лучше, какую культуру хочет или уже имеет организация,
хотите ли вы изменить ее?
 Луис Герстнер [19] сделал глубокое практическое замечание относительно культуры,
сказав: «Работая в IBM, я пришел к выводу, что культура — не просто один из аспектов кар-
тины, это сама картина. В конце концов, что такое организация, если не совокупность спо-
собностей ее сотрудников создавать ценность?»
Фактически же сказано, что нужно встроить культуру в ДНК организации.
Какое влияние будет оказывать проект BPM на культуру организации? Очевидно, это
будет зависеть от выбранного сценария внедрения:
 в случае «пилотного проекта» и «вне поля зрения» будет трудно повлиять или прове-
сти крупную реформу культуры;
 в случае «рулевой» будет больше возможностей оказывать влияние.
Но нельзя недооценивать влияние, которое может оказать на культуру организации ра-
зумно небольшая группа проекта.
Кейс: влияние небольшого проекта на общеорганизационную культуру
Много лет назад мы принимали участие во внедрении банковской системы в строитель-
ной компании со многими филиалами. Недавно приватизированная организация с трудом
выпутывалась из наследия государственной бюрократии.
Персонал организации, участвующий в проекте, был малопродуктивен и слабо мотиви-
рован по сравнению с аналогичными организациями частного сектора. Мы ввели в группе
проекта наделение полномочиями и сделали работу «занимательной». Персонал проекта не
просто повысил продуктивность до 200–300% выше норматива внутри организации, но эта
культура стала проникать в остальную организацию и действовать в положительном направ-
лении.
Хотя группа проекта BPM состояла из относительно небольшого количества людей, она
оказала влияние на всю организацию.
Вывод. Вы не можете не влиять на людей, с которыми общаетесь.
Существует три простых шага, широкое распространение которых может помочь про-
цессу управления изменениями персонала:
1. Выработать краткий хлесткий посыл. «Выигрывай, работая в команде». Этот пример
из Луиса Герстнера [19] дает представление о краткости, четкости и хлесткости такого по-
сыла.
2. Разработать кодекс поведения (устав), показывающий изменения в поведении, необ-
ходимые для перехода от текущего положения в новое.
3. Разработать комплекс принципов, которых все должны придерживаться внутри орга-
низации.
Важно это все зафиксировать в виде документов и довести их до всех сотрудников орга-
низации.
Шаг 6. Как осуществить перемены – не рисунке Как перейти в это состояние? –
С.К.
На многие вопросы типа «как?» ответы получены в предшествующих шагах в этой гла-
ве, и мы не будем повторяться, а кратко остановимся на некоторых важнейших элементах.
Для начала важно понять, что ни в коем случае нельзя недооценивать время и усилия,
которые потребует программа перемен. Выбранный сценарий проекта повлияет на роль ли-
деров в программе. В случае сценария «обычная работа» или «рулевой» могут понадобиться
сотни часов личного времени лидера, чтобы «спуститься в окопы» и поговорить с людьми в
организации, объяснить им видение перспективы, принципы и кодекс поведения, а затем по-
стоянно и строго «вести своим примером». Но и в этой ситуации для небольшой организа-
ции перемены отнимут минимум три года, а в транснациональной корпорации — более пяти
лет; при этом нет никаких гарантий. Хотя лидер играет решающую роль, донесение согласо-
ванного посыла применимо ко всему руководству, главам коллективов сотрудников и людям
внутри организации.
Согласованность, настойчивость и общение — «мантра» программы культурных пере-
мен организации.
Первый шаг — анализ требований проекта BPM на основе выбранного сценария, по-
скольку просто необходимо решить, что и каким образом менять:
 потребует ли проект изменения всей организации или только ее отдельных частей;
 когда определились с этим, обозначьте глубину и широту охвата программы перемен;
  придерживайтесь подхода «глубоких», а не «мелких» усилий; понимание этого по-
требует больше времени и сил, но дает значительно более устойчивые результаты;
 свяжите программу перемен с различными аспектами этапа работы с персоналом об-
щей схемы.
Стейс и Данфи [71] составили чрезвычайно полезную сводку решений и результатов
программы перемен (табл. 25.2).
Таблица 25.2. Сводка решений и результатов программы перемен (Стейс и Данфи)
Радикальное делегирование власти и полномо- Меньше уровней иерархии - лучше про-
чий цесс принятия решений
Больше делегированной власти - больше
доверия

Свобода и ответственность Наделение полномочиями и властью -

меньше правил
Четкое видение и понимание целей групп
/ коллективов

Широко образованные и обучающиеся личности Многофункциональность персонала

Технические умения в каждом коллективе

Постоянное обучение и образование
Более высокие уровни профессионализма

Неустанное совершенствование Подчеркивать значение программы по-

вышения производительности
Данные о показателях производительно-
сти для персонала
Связь с усовершенствованием процессов

Вознаграждение за профессионализм и высокие Увязка с измерениями эффективности и

показатели в работе вознаграждениями

Люди — в центре внимания Подчеркивать важность охраны труда и

здоровья
Обеспечить персонал «инструментом»
для выполнения своих функций
Перестройка процессов и переформули-
рование ролевых функций самими члена-
ми группы/коллектива
Рассматривая и оценивая действия, предпринимаемые по программе управления изме-
нения персонала, нужно сверять задачи и предлагаемые действия, как с выбранным сценари-
ем реализации проекта, так и со следующим правилом:
Если действие:
 не дает вклад в ценность/пользу для клиента;
 не повышает продуктивность;
 не укрепляет мораль,
не делайте его.

Глава 26. Лидерство

Назначение
Почему лидерство (рис. 26.1) — один из неотъемлемых атрибутов успешного проекта
BPM? Это очень важный вопрос. Ответ частично заключается в выбранном сценарии проек-
та BPM.
 Сценарии «обычная работа» и «рулевой» требуют от руководителей / лидеров:
 высокой степени понимания BPM и
 поддержки, без которой проекту будет очень проблематично получить финансирова-
ние и преданность организации и бизнеса.
Проекты по этим сценариям, весьма вероятно, относятся к высоко значимым и сильно
влияющим на бизнес. Руководители не должны давать разрешение на такие проекты, если не
будут поддерживать их.
Сценарии «пилотный проект» и «вне поля зрения», в общем, не требуют столь высокой
степени понимания и настроя руководителей. По самой своей природе такие проекты не бу-
дут слишком заметны в организации. Конечно, им понадобится поддержка и понимание ру-
ководителей, но обычно (хотя и не всегда) от руководителей более низкого звена, чем в слу-
чае двух ранее упомянутых сценариев.
Осуществление
Мы не приводим шаги по реализации для данного атрибута проекта BPM, поскольку это
не имеет смысла. Вместо этого мы рассмотрим следующие моменты:
1. что означает лидерство в проекте BPM?
2. зона влияния лидерства? – стр. 200
3. как взаимосвязаны стратегия организации и лидерство? – стр. 202
4. шесть стилей лидерства и их влияние на программу BPM – стр. 203;
5. взаимоотношения — лидерство на всех уровнях внутри организации сводится к взаи-
моотношениям – стр. 206.
После этого мы соберем все это в таблицу уровней и компонентов лидерства.
Лидеры должны вести настолько далеко, насколько они сами могут зайти, а затем ис-
чезнуть. Их пепел не должен затушить зажженный ими огонь.
Г. Уэллс
1. Что означает лидерство в программе/проекте BPM? Суть лидерства ухвачена в про-
стой мысли: мерилом лидерства является стабильно и безупречно работающая система,
которую оставляет лидер после своего ухода со сцены.
Чиббер (Chibber), [7]
По первому прочтению этой сентенции можно подумать, что лидер — это высший руко-
водитель, но если прочитать ее внимательно, становится понятно, что она применима к ли-
дерам любого уровня внутри организации. С целью рассмотрения лидерства в контексте
программы или проекта BPM выделим три уровня лидерства:
 высший руководитель (высший исполнительный орган), должностное лицо высшего
ранга или менеджер бизнес-подразделения.
 Спонсор программы/проекта, директор программы, а также менеджер проекта.
 Персонал (члены группы проекта и бизнес-персонал). Важно понимать, что этот кон-
тингент обеспечивает ведущую роль друг для друга и другим заинтересованным ли-
цам. Они являются образцом для подражания (ролевой моделью) и лидерами измене-
ний в небольших компактах организации по сравнению с лидерами высшего уровня.
Роль каждого лидера зависит, как подчеркнуто выше, от выбранного сценария BPM.
 2. Зона влияния. Лидеры разных уровней могут иметь различную степень влияния на
проект BPM, организацию, персонал и его рабочую среду. На рис. 26.2 показаны сферы вли-
яния лидерства в общем виде.
Степень влияния трех названных выше уровней лидерства на компоненты оказывается
различной (см. рис. 26.2):

 лидеры уровня 1 (высший руководитель — СЕО, должностные лица высокого ранга

или менеджер бизнес-подразделения) будут влиять на все или большинство компонентов на
рис. 26.2;
 лидеры уровня 2 (спонсор программы/проекта, директор программы и менеджер про-
екта). Сфера их влияния меняется в зависимости от масштаба и сценария предпринимаемого
организацией проекта: от исключительно бизнес-подразделения, до почти всей организации
и, возможно, нескольких внешних заинтересованных сторон внутри группировок рынка и
ресурсов. Маловероятно, чтобы это влияло на рабочую среду и инвесторов или конкурентов,
хотя крупная программа BPM может влиять на производимую организацией ценность и от-
ражаться на инвесторах и конкурентах. Некоторые лидеры уровня 2 могут иметь интенсив-
ные плотные контакты как внутри, так и вне организации, в силу личных связей и/или про-
должительности работы в организации;
 лидеры уровня 3 (члены группы проекта и бизнес-персонал) неизбежно будут иметь
сферу влияния либо внутри своего бизнес-подразделения, либо ограниченную рамками ор-
ганизации.
Независимо от уровня лидерства упрощенно можно утверждать, что главное качество
лидера — пассионарность, близко за которым идут честность и моральная чистота, а так-
же настоящая способность слушать. Это справедливо для всех уровней лидерства, но, оче-
видно, значимость растет с повышением уровня лидерства внутри организации.
Одно из самых сложных заключений, к которому я пришел, будучи генеральным дирек-
тором, состоит в том, что на самом деле мой главный инструмент — это мое душевное
состояние … Моя повседневная жизнь проходит в затратах энергии, и сохранение душев-
ной концентрации требует постоянных усилий.
Хоули (Hawley) [34]:
Пассионарность заключается в эмоциональности: острое захватывающее чувство убеж-
денности. Синонимами могут служить энтузиазм и устремленность («энергичное и неосла-
бевающее стремление к цели или преданность делу» — онлайновый словарь Merriam-
Webster). Мы считаем, что лидерство в этом плане также подразумевает внимание к различ-
ным выполняемым задачам. Если значительный проект или программа BPM не располагает
пассионарностью и вниманием лидеров организации, не стоит ее затевать — это будет
нескончаемая битва, что поставит проект под существенный риск.
Чрезвычайно важно понимать и проработать сферу влияния лидеров уровней 1 и 2.
«Ключ к девяноста девяти — это один. Ваше отношение к одному человеку показывает
отношение к девяноста девяти, поскольку все люди — в конечном итоге, один» [34].
Стивен Кови
Это означает, что лидеры всех уровней должны «делом подтверждать слова», — люди
тонко улавливают несоответствие между словами и поступками. Такое несоответствие обо-
значает разрыв между моралью и честностью. Когда лидеры всех уровней жалуются на от-
сутствие преданности людей внутри организации, обычно это является результатом степени
преданности лидеров своему персоналу. «Делом подтверждать слова» — важнейший прин-
цип поведения лидеров всех уровней.
Кейс: BPM — еще один проект
Однажды мы убеждали в преимуществах BPM руководителя высокого ранга, который
сказал, что только что побывал на двухдневном совещании по планированию со своим пер-
соналом, и там было названо шестьдесят семь проектов на следующий год. Он был настоль-
ко поражен потенциальными выгодами BPM для своей организации, что намеревался серь-
езно подумать, не сделать ли BPM 68-м проектом.
Мы предложили не делать этого, потому что он не смог бы уделить проекту должного
внимания.
Вывод. Добейтесь, чтобы проект BPM был одним из ключевых приоритетов высшего
руководства. Если руководитель не сможет уделять ему достаточно внимания, рассмотрите
возможность сценария «вне поля зрения» или «пилотный проект» с менеджером среднего
звена.
3. Как взаимосвязаны стратегия организации и лидерство? Речь идет о разработке
стратегии организации лидерами уровня 1. Как указывалось на этапе разработки стратегии
общей схемы, мы не даем рецептов или методик, но, по нашему мнению, стоит добиться по-
нимания того, что является стратегией, в чем ее польза для организации и, следовательно,
проекта BPM.
Стратегия — это не план, а «целенаправленный процесс вовлечения людей изнутри и
извне организации к проработке новых путей движения вперед» (Стейс и Данфи, [71]).
Должна быть связь между стратегией, ее реализацией и убеждением в необходимости такой
стратегии персонала.
Лидерство заключается во «всеобщем вовлечении» не только на уровне разумности, но
и на уровне эмоций, в сердцах людей, чтобы их действительно «заводил» сам процесс, они
отождествляли себя с ним и сами становились лидерами.
Блаунта (Blount) [4]:
Вдохновляющая стратегия или озарение редко мотивируют людей. Люди стараются из-
бежать трудностей и стремятся к удовольствию. Столкновение с реальностью может причи-
нить боль. Лидер должен создать среду, где «правда услышана, и горькие факты признаны»
(Коллинз — Collins, [8]).
Как говорилось в главе 25, упрощенно можно считать, что есть два способа убедить лю-
дей измениться. Выбранный способ зависит от организации, конкретных обстоятельств и
стиля лидерства руководителя.
1. Был применен при перестройке в IBM в 90-х годах прошлого века
Если сотрудники не верят в существование кризиса, он не пойдут на жертвы, необхо-
димые для перемен. Никто не любит перемен. Поэтому обязательно нужен кризис, и в обя-
занности высшего руководителя входит сформировать и донести ощущение кризиса, его
масштаб, серьезность и влияние.
Также важно, чтобы руководитель был способен объяснить, как выйти из кризиса: но-
вую стратегию, новую модель компании, новую культуру. Все это требует огромной убеж-
денности руководителя и его способности общаться, общаться и еще раз общаться.
Я считаю, что никаких институциональных преобразований не произойдет без убеж-
денности и готовности руководителя постоянно стоять перед лицом сотрудников и гово-
рить на простом, ясном и убедительном языке, который приводит в действие усилия по
всей организации.
Луис Герстнер
 2. Тоньше и требует от лидеров умения дать людям возможность осознать, что имеется
«проблема», донести до них масштаб проблемы и необходимость перемен. Люди должны
понимать, что произойдет с организаций и ими самими, если проблема не решится.
Стратегию нужно доносить не только до людей внутри организации, но и постоянно
убеждать в ней все заинтересованные стороны, пока она не привьется в культуре организа-
ции. Люди должны воспринять ее со всей остротой и увлеченностью.
Определив стратегию, перспективы организации и продолжая доводить их до людей,
необходимо постоянно следить за ними. Высший руководитель редко может «изобрести»
абсолютно совершенную стратегию или даже просто выдумать собственную. Стратегии
обычно дают общее видение или направление движения вперед, а подробности уточняются и
реализуются ниже в иерархии организации.
Стратегия — это поиск направлений, которые зарядят энергией жизнь организации;
структуры обеспечивают социальную организованность, необходимую для воплощения
стратегии … Чтобы быть эффективными, стратегия и структура должны постоянно
переосмысливаться и перестраиваться.
Стейс и Данфи
Но при всей важности стратегии ее нужно видеть в контексте, потому что для роли ли-
дера важнее «состояние ума, чем ладно скроенные и безупречно вычерченные планы» (Хо-
ули, [34]). Лучше быть ярко пассионарным лидером, честным, высокоморальным и способ-
ным выслушивать, но без стратегии, чем наоборот.
3. Шесть стилей лидерства и их влияние на программу BPM. На выбор организацией
или бизнес-подразделением сценария проекта BPM оказывает влияние стиль лидерства в ор-
ганизации. Стиль лидерства — это «не стратегия, а подход к ней: он определяется ролью ли-
деров фирмы» [38].
Кин выделил шесть стилей лидерства (он назвал их «стратегическими стилями»), и это
соответствует тому, что мы наблюдали в организациях, где нам приходилось работать:
1. преобразующее лидерство.
2. Делегирование мандата на перемены.
3. Реакция на остроту проблемы.
4. Индивидуальная инициатива.
5. Устойчивое совершенствование.
6. Оппортунизм.
Кратко остановимся на каждом стиле, связывая их с вероятными сценариями реализации
BPM.
4.1. Преобразующее лидерство. Этот тип лидерства требует уникальности лидера,
который после завершения преобразований должен стать либо героем, либо негодяем. Лидер
(уровень 1 или 2) персонально возглавляет программу перемен, убеждая в ней все заинтере-
сованные стороны, внутренние и внешние, а это очень рискованная деятельность. Нельзя
недооценивать время, требуемое для преобразований: перемены могут длиться от пяти до
десяти лет. Спонсор проекта уровня 2 или менеджер проекта могут обеспечить этот тип ли-
дерства, если они достаточно сильные личности, чтобы убедить в программе, проекте пере-
мен остальную организацию.
Например, один австралийский банк реализовал следующую программу. Президент бан-
ка выделил $1,5 млрд. на три года на перестройку операционных процессов банка, повыше-
ние их эффективности и ориентированности на клиентов. Он лично занял место «рулевого»,
чтобы убедить в этой программе менеджеров, персонал и инвестиционное сообщество. На
момент написания книги программа была на половине пути и уже давала результаты; но на
начальной стадии президент банка подвергся жесткой критике в финансовой прессе и со
стороны персонала. Итоги же, по заключению финансовой прессы и инвестиционного сооб-
щества, были успешными.
Принятый сценарий, наиболее вероятно, был случаем «рулевого», поскольку ожидания
от перемен были очень высоки, а полномочия и власть очевидны.
4.2. Делегирование полномочий. Кин утверждал, что этот стиль лидерства присущ
около трети организаций. В этом случае лидер (высший руководитель) дает четкий мандат
на перемены, но стратегия формулируется и доносится лишь в обобщенных терминах,
например «нам нужно быть более клиенто-ориентированными», «нам нужно быть более
конкурентоспособными, поэтому нужно сократить расходы на $N млн».
 Исполнение поручается руководителям более низкого уровня, что может приводить к не-
четкости посылов и сомнениям относительно путей реализации стратегии. Для лидеров
уровня 2 это равносильно тому, что спонсор или менеджер проекта в общих словах объяс-
няют группе проекта, какие итоги ожидаются от проекта, а главы групп проекта обеспечи-
вают достижение результата. Трудность такой ситуации в том, чтобы связать предпринима-
емые действия с желаемыми задачами проекта, и в координации между различными главами
подгрупп проекта. Положение усугубляется тем, что менеджер проекта обязан обеспечить
достижение целей.
Такой стиль лидерства обычно порождает проекты и программы мелких постепенных
шажков, например BPR.
Принимаемый сценарий — либо «пилотный проект», либо «вне поля зрения», которые
работают до тех пор, пока не будет более четкого понимания направления движения.
Кейс: что нам делать?
Мы были свидетелями того, как руководитель инициировал программу, рассчитанную на
несколько лет, результатом которой должно было быть ежегодное сокращение расходов ор-
ганизации на $25 млн. Эта программа была «спущена» в организацию, а прямым подчинен-
ным было поручено «осуществить» ее.
Реакцией тех, кто был подальше от высшего руководства, было неверие и замешатель-
ство. Люди не понимали, чего ждать: руководитель хочет просто сократить расходы за счет
экономии на персонале и сократить другие расходы? Это отразилось на развитии, уровне
сервиса и будущих возможностях роста бизнеса.
Программа «хромала» полтора года, а потом, после проб и ошибок, прямые подчиненные
высшего руководителя поняли, чего он от них ожидает.
Вывод. Стиль руководства, более настроенный на преобразования, дал бы общее виде-
ние, которое позволило бы организации набрать импульс значительно быстрее, с хорошими
итоговыми выгодами.
4.3. Реакция на остроту проблемы. По сути дела, это кризисное управление и
наиболее распространенный стиль лидерства. Обычно он возникает как реакция на конку-
рента или рыночную ситуацию. Реинжиниринг, сокращение расходов и штатов являются ти-
пичными подходами, которые, как правило, возглавляет жесткий «крутой» руководитель вы-
сокого ранга с репутацией человека, умеющего добиваться решения поставленных задач.
Хотя кризис может мобилизовать организацию и привести к результатам, гораздо лучше
действовать упреждающе и предвидеть события, а не реагировать на них.
Выбранный сценарий реализации BPM будет случаем:
 «рулевого», если высшее руководство убеждено в выгодах, извлекаемых из внедрения
BPM, или
 «вне поля зрения», если убежденность и понимание выгод BPM недостаточно зрелые.
В любом случае внедрение будет носить характер срочных мер и связываться с немед-
ленными результатами, что иногда может быть нереалистично или проблематично.
Руководство проекта (уровень 2), члены групп проекта и бизнес-персонал (уровень 3),
работая в кризисном режиме, могут быть контрпродуктивными и пойти на компромисс по
результатам проекта или, по крайней мере, внести в него значительные риски, поскольку
слишком сильное давление или срочность могут приводить к ошибкам и упущениям.
4.4. Индивидуальная инициатива. Этот стиль лидерства полагается на действую-
щего из лучших намерений руководителя-лидера, который может осуществить изменения.
Обычно все начинается с «решения», обнаруженного этим лидером, которое он считает
чрезвычайно полезным для организации, и ищет применение этому решению.
Сценарий обычно следует случаю «вне поля зрения», пока не проявятся результаты. При
успехе лидера будут считать великим инициатором, и решение распространится по органи-
зации. Нельзя недооценивать влияние, которое этот стиль может оказывать на организацию.
Руководители-лидеры уровней 2 и 3 тоже могут инициировать мероприятия, дающие вы-
годы (и вызывающие риски) для организации, просто масштаб тем меньше, чем ниже уро-
вень лидера.
Иногда, если пришло время, даже слабые вариации могут повлечь за собой взрывную си-
туацию внутри организации. Часть роли лидера состоит в создании обстановки, при которой
отдельные люди смогут взять инициативу на себя, получить полномочия и право на неудачу
без взаимных обвинений.
 4.5. Устойчивое совершенствование. Такой тип программы улучшений допустим,
только если организация является лучшей в своей области (мировым лидером).
Пол О’Нил, президент компании Alcoa, дал блестящую характеристику, которая цитиро-
валась в главе 17, но ее стоит повторить здесь: постоянное совершенствование — правиль-
ная для вас концепция, если вы являетесь мировым лидером. Если вы утратили лидерство,
эта идея ужасна. Ну а если вы далеки от мирового стандарта, она просто катастрофич-
на, и вам нужен быстрый качественный скачок.
Toyota — еще один прекрасный пример для сторонников программ постоянного совер-
шенствования. Эта компания никогда не почивает на лаврах; постоянно напряженно работа-
ет, чтобы становиться все лучше и лучше.
Если вы не являетесь мировым лидером, устойчивое совершенствование — не тот стиль
руководства, который нужно принять. В данном случае недостаточно быть лучше, чем вы
были в прошлом году, или даже лучше ваших конкурентов — нужен радикальный скачок в
производительности. В этой ситуации должен действовать сценарий «рулевой» или «пилот-
ный проект» (для проверки и быстрого усвоения уроков), за которым сразу последует сцена-
рий «рулевой».
Данный стиль лидерства следует принять на всех уровнях руководства внутри организа-
ции. Вклад в устойчивое совершенствование организации должны вносить все сотрудники,
причем постоянно.
4.6. Оппортунизм. Данная стратегия может оказаться чрезвычайно удачной в неко-
торых организациях. Это уже не кризисное управление, как реакция на остроту проблемы,
но также не упреждающее действие, и уж тем более не устойчивое совершенствование. Ли-
деры, стоящие на позициях такого стиля руководства, стремятся предотвратить кризисы, но
являются ведущими в отрасли и не отрываются далеко вперед от своих конкурентов. Такие
лидеры могут немного увлекаться модой в попытках применить последние управленческие
штучки (TQM, BPR, Six Sigma, BPM).
Они будут скорее склоняться к сценарию «пилотный проект», чтобы апробировать под-
ход, или, если уверены в технологиях и своей способности контролировать их, — к сцена-
рию «рулевой».
Опять же, обязанностью на всех уровнях является постоянное отслеживание и поиск
возможностей для организации. Лидеры уровней 1 и 2 должны обеспечить, чтобы культура
организации продвигала идеи всех людей и поощряла выдвижение идей.
Будет правильно сказать, что лидеры должны применять в организации различные стра-
тегические стили в разное время. Иногда программа BPM должна двигаться мелкими шаж-
ками, а иногда должна быть радикальной. Оба варианта могут подходить одновременно, но в
разных бизнес-подразделениях. Преобразование организации — вещь трудная, и нет един-
ственного правильного пути его осуществления.
5. Общение/обмен информацией. Даже если лидер сформулировал и вложил в сотрудни-
ков прекрасную стратегию, она бесполезна, если он не привлек на свою сторону большин-
ство. Так что люди — важнейший фактор. Как заметил Джим Коллинз (Jim Collins) [8], ста-
рая мудрость, согласно которой «люди — главный актив», оказывается неверной. «Правиль-
ные» люди — вот самый главный актив. Возьмите с собой нужных людей, избавьтесь от не-
нужных, и тогда «правильные» люди помогут выстроить стратегию.
Так что сначала сделайте выбор «кто» (привлеките правильных людей), а затем прики-
дывайте, «как» и «что».
Лидерство, в частности, состоит в том, чтобы «заразить» людей идеей, желанием достичь
результатов и гордостью за достижение этих результатов.
Настоящие лидеры видят разницу между возможностью людей быть услышанным и уче-
та их мнения. Иерархические организации испытывают трудности, давая людям возмож-
ность быть услышанным. Мешает синдром «я здесь главный». В наши дни это уже становит-
ся меньшей проблемой, но так ли это? К сожалению, нет, по нашему опыту.
Кейс: иерархический стиль управления
В организации была чрезвычайно выражена культура и стиль управления - равенство.
Высший руководитель считал себя просто играющим роль для людей, а культура давала
возможность всем быть услышанными и уважаемыми. Организация быстро развивалась, по-
стоянно показывая рост 35%.
 Со сменой руководителя изменился стиль лидерства в сторону иерархического и ко-
мандно-административного. Когда принимались решения, с которыми большинство было
несогласно, и сотрудники высказывались «против», им рекомендовали подумать о собствен-
ной работе, а управление организацией оставить тем, кто за это отвечает.
В течение нескольких лет развитие пострадало, организация уменьшилась в размерах, и
произошло сокращение персонала. Несколько лет потребовалось руководству, чтобы изме-
ниться, в организации начали восстанавливаться и культура, и рост.
Вывод. Насаждение «правильной» культуры в организации отнимает много времени и
требует упорства, преданности и настойчивого согласованного подхода. К сожалению, со
сменой стиля руководства (на всех уровнях организации) очень просто утратить «правиль-
ную» культуру.
Если:
 организация действует, как машина, контроль имеет смысл.
 организация — процессная структура, то попытка установить контроль через по-
стоянную структуру - самоубийственна.
 считать, что действовать ответственно — это осуществлять контроль посред-
ством вмешательства везде, где можно, то нельзя надеяться ни на что, кроме того, что
уже и так есть — перемалывающую силы мельницу и разрушающее жизнь напряжение.
Уитли (Wheatley) [81]
Вместо контроля нужен порядок. Однако необходимо понимать, что «беспорядок может
быть источником порядка, и что развитие лежит в неравновесии, а не в балансе» [81]. Нерав-
новесие чрезвычайно неудобно людям вообще, даже некоторым лидерам. Нормальная реак-
ция — сделать все необходимое для подавления возбуждения.
Некоторые лидеры специально вызывают перегрузки и неопределенность (поднимая со-
трудников из их уютных кресел), потому что понимают, что из неопределенности рождается
порядок и новые перспективные идеи и возможности, которые редко возникают в любых
других ситуациях.
Важное качество для лидера (высшего руководителя) — уметь выработать увлекающее
видение перспективы или стратегию, которую другие лидеры организации могли использо-
вать как опору для поддержания целенаправленности.
Из такого беспорядка или хаоса будут появляться сюрпризы, и хотя как консультантам
нам всегда говорили, что сюрпризов быть не должно, это не так в случае ведущей роли.
«Неожиданность — единственный путь к открытию» [81], и чтобы совершать открытия, ли-
деры должны формировать обстановку, в которой ошибки допустимы. Люди учатся на
ошибках, и если не разрешать им пробовать и проигрывать, они перестанут пробовать. Это
применимо ко всем трем уровням лидерства: от высшего руководителя до глав групп.
6. Взаимоотношения — основа всего, что мы делаем.
В области взаимоотношений нет предсказуемости человеческого потенциала … Никого
из нас нет отдельно от взаимоотношений с другими людьми. Различная обстановка про-
буждает в нас одни качества, оставляя скрытыми другие.
Уитли [81]
«Двенадцать процентов эффективного управления (эвфемизм лидерства в науке управле-
ния) — это знания, а восемьдесят восемь — правильное обращение с людьми».
Чиббер [7]
Так что же больше влияет на поведение: система или отдельные люди?
«Поместите хорошего работника в плохую систему, и система всегда победит».
Раммлер (Geary A. Rummler) [64]
Справедливо и обратное: плохие работники плохо работают и в хорошей системе (хотя,
надеемся, не настолько).
« …бывает по-разному. Нет необходимости выбирать людей или систему. Важны отно-
шения, создаваемые между человеком и обстановкой» (или системой).
Уитли
Очевидно, что если системы оценки эффективности и вознаграждений увязаны со стра-
тегией, такая синхронность дает мощный толчок стремлению к эффективности исполнения.
Но хотя вознаграждения важны, они не достигнут целей. Если вы заполучили «правильных»
людей, они заразят остальных «правильных» людей (цепная реакция перемен), и гордость за
достижения станет мотивирующим стимулом. Приятно получать награды и признание, и это
поможет устойчивости в более длительном плане.
Если вам потребовались вознаграждения и компенсации, чтобы заполучить «правиль-
ных» людей, значит, у вас много «неправильных» сотрудников. Первые никогда не удовле-
творятся вторым местом, независимо от системы вознаграждений, им всегда нужно добиться
чего-то выдающегося.
Так что же должны сделать лидеры в связи с внедрением BPM в своей организации?
Во-первых, лидеры должны координировать и содействовать отношениям между собой
и менеджером проекта, а также заинтересованными лицами (внешними и внутренними).
Во-вторых, с чего начинать? Нам нравится пословица «дорога в тысячу ли начинается с
первого шага» (Конфуций).
Другие, более распространенные рекомендации:
 думайте глобально, действуйте локально;
 мыслите масштабно, начинайте с малого.
Кейс: вознаграждения могут мотивировать неверно
Нам встречались примеры, когда руководитель высокого ранга в организации был моти-
вирован исключительно через KPI, и его премии были привязаны к ним. Это определенно
означало, что нормативы, установленные высшим руководителем, достигались, даже если
они не соответствовали долгосрочным интересам организации.
В одном случае заменялась громоздкая старая система (весь бизнес работал на ней).
Планируемые усилия по внедрению были недооценены (ни по чьей вине; просто у организа-
ции не было подобного опыта). Была установлена дата пуска системы, но когда недооценка
стала очевидной, понадобилось отсрочить запуск на три месяца.
Высший руководитель настоял на пуске системы в исходную дату, что было сделано и
привело к невообразимому хаосу в работе организации.
Позже обнаружилось, что у высшего руководителя огромная составляющая премии была
увязана с соблюдением исходной даты пуска системы.
Вывод. Увязка вознаграждений и эффективности/производительности хотя и важна, но
должна быть адекватной.
Несомненно, внедрение BPM по всему предприятию очень редко, и, скорее всего, слиш-
ком амбициозно для большинства организаций. Выше было предложено четыре сценария —
методы локальных действий, в процессе которых, начиная с малого, накапливается уверен-
ность, опыт и формируется основа самофинансирования для дальнейших внедрений:
1. «обычная работа»,
2. «рулевой»,
3. «пилотный проект» и
4. «вне поля зрения».
Нельзя недооценивать воздействия обстановки «расползания» изменений внутри орга-
низации. Многие чрезвычайно успешные крупные программы начинались с малого и разви-
вались до изменений всей организации.
Заключение
В табл. 26.1 сведены уровни лидерства и, чтобы показать влияние, которое каждый уро-
вень лидерства будет (или может) оказывать внутри проекта BPM.
Таблица 26.1. Составляющие (шесть компонент) и уровни лидерства
Уровень лидерства Составляющая лидерства Роли и ответственность
1. руководитель Сфера влияния  Вся организация, весь
высокого ранга, ме- персонал и руководство.
неджер бизнес -  Все составляющие сфе-
подразделения ры влияния лидерства.
 Стратегия влияет на ре-
сурсы, рынок, конкурентов и
внешнюю обстановку
Стратегия организации  Стратегия - последова-
тельное направление движе-
ния, обеспечивает целеполага-
ние
 В чем значение страте-
 гии?
 Каким образом содей-
ствует программе/проекту
BPM?
 Стратегическое согла-
сование — продолжать разъ-
яснять увязку проекта со стра-
тегией организации: как про-
ект укладывается в стратегию
и содействует ее реализации.
 Назначение хозяев про-
цессов.
 Финансирование проек-
та.
 Формирование проек-
тов для осуществления страте-
гии.
 Отвечает за доведение
стратегического посыла и
убеждение в нем всей органи-
зации
Стиль лидерства  Личное дело руководи-
теля. Соответствует одному из
описанных в этой главе.
 Просвещенные лидеры
берут на вооружение стиль ли-
дерства в зависимости от кон-
кретной ситуации и изменяют
его по мере перемен в органи-
зации
Общение/обмен информацией  Общения не может быть
слишком много.
 Слова подтверждайте
делом.
 Постоянно пропаганди-
руйте стратегию.
 Применяйте формаль-
ные и неформальные методы.
 Откликайтесь на обрат-
ную связь.
 Общение - глава 25
Взаимоотношения  меняются в зависимо-
сти от роли.
 Высший руководитель
направляет подчиненных, со-
здает доверительные отноше-
ния и симпатии в организации
2. Спонсор Сфера влияния  Люди в проекте, вклю-
программы/проекта, чая сквозные процессы, так что
директор програм- вероятно пересечение границ
мы и менеджер про- между структурными подраз-
екта делениями внутри организа-
ции.
 Уровни лидерства 1 и 3
— лидерство и управление.
 Заинтересованные сто-
роны — участники проекта и
 около него.
 Службы сопровожде-
ния/поддержки внутри органи-
зации.
 Рынок: клиенты, каналы
и дилеры.
 Ресурсы: персонал, по-
ставщики и технологии.
 Возможно, конкуренты
Стратегия организации  Понимать, как и почему
была сформирована стратегия
организации.
 Обеспечивать обратную
связь для стратегии.
 Разработать подробный
план реализации стратегии.
 Отвечать за реализацию
проектов.
 Помогать убеждать лю-
дей (проекта, бизнес и заинте-
ресованных лиц) в правильно-
сти стратегии
Стиль лидерства  Работает согласно сти-
лю лидерства высшего руково-
дителя и других лидеров уров-
ня 1, понимает их стиль и при-
спосабливается к нему.
 Твердо нацелен на реа-
лизацию проектов.
 Обеспечивает реализа-
цию проектов в срок и в рам-
ках выделенного бюджета.
 Обеспечивает реализа-
цию ценности в проектах.
 Доступен членам групп
проекта и бизнес-персоналу
Общение/обмен информацией  Общения не может быть
слишком много.
 Делом подтверждать
слова.
 Постоянно пропаганди-
ровать стратегию проекта и его
результаты.
 Применять формальные
и неформальные методы.
 Откликаться на обрат-
ную связь.
 Общение - глава 25
Взаимоотношения  Лидеры уровня 1.
 Спонсор, директор и
менеджер проекта должны
поддерживать прочные, дове-
рительные и честные взаимо-
отношения.
 Члены группы проекта.
 Сотрудники бизнес -
подразделений, связанные с
 проектом и участвующие в
нем.
 Поставщики.
 Заинтересованные сто-
роны проекта (клиенты, по-
ставщики и заинтересованные
в бизнесе лица)
3. Сотрудники Сфера влияния  Коллеги по работе.
(члены группы про-  Лидеры уровня 2.
екта и персонал  Клиенты, поставщики и
бизнес - подразде- другие заинтересованные сто-
лений) роны
Стратегия организации  Необходимо понимать
стратегию и ее значение для
организации.
 Необходима увлечен-
ность реализацией стратегии
через проекты и другими сред-
ствами
Стиль лидерства  У каждого свой стиль
Общение / обмен информацией  Задавайте вопросы.
 Реализуйте обратную
связь
Взаимоотношения  Лидеры уровня 2.
 Коллеги по работе и ра-
ботники организации.
 Клиенты, поставщики и
другие заинтересованные сто-
роны в своей сфере влияния

Часть III. BPM и организация

Эта часть книги предназначена главным образом для исполнительных должностных лиц
организации, хотя менеджер проекта и члены групп могут найти в ней полезную и важную
информацию. Она дает глубинное понимание того, каким образом установить уровень го-
товности организации или подразделения бизнеса к проекту BPM, и как вживить BPM в ор-
ганизацию, чтобы внедрить культуру непрерывного совершенствования бизнес-процессов.
Главу 27 совместно написали профессор Майкл Розманн (Michael Rosemann) и Тоня де
Бруин (Tonia de Bruin) из Технологического Университета Квинсленда, а также Брэд Пауер
(Brad Power), исполнительный директор Исследовательского центра управления процессами
Бэбсон колледжа в Бостоне. Тоня — бывший консультант и сейчас пишет диссертацию, ра-
ботая с Майклом и Брэдом по разработке модели зрелости BPM, которую можно будет ис-
пользовать как глобальный стандарт.
В этой главе дается краткий обзор модели и результатов их исследований. Хотя многие
организации и частные лица разработали модели зрелости BPM, представленная модель
тоньше и сложнее, чем ее предшественницы, и чрезвычайно практично подходит к конкрет-
ным сложностям BPM. В ней читателю дается возможность:
 оценить уровень зрелости своей организации в управлении бизнес-процессами и
 разработать дорожную карту продвижения вперед.
В главе 28 на основе информации об общей схеме и модели предлагаются методы внед-
рения BPM в организацию в зависимости от уровня понимания и принятия процессов с це-
лью:
 создания рабочего бизнес - режима, который будет постоянно отслеживать, и улуч-
шать бизнес-процессы;
 создания культуры, которая на передний план выдвигает совершенствование процес-
сов;
 обеспечения маневренности организации, непрерывного усовершенствования и воз-
можностей бизнеса, которые не появились бы в противном случае.
 Глава 27. Зрелость BPM
Майкл Розманн (Michael Rosemann)
Тоня де Бруин (Tonia de Bruin)
Брэд Пауэр (Brad Power)
Введение
Во всей книге повторяется, что BPM — это комплексная всесторонняя практика управ-
ления организацией, требующая:
 понимания и привлечения высшего руководства,
 четко определенных ролей и процессов принятия решений как части корпоративного
руководства BPM,
 адекватных методологий BPM, распознающих процессы информационных систем,
 образованного и хорошо подготовленного персонала и
 культуры, восприимчивой к бизнес-процессам.
Корнями BPM уходит в ряд подходов, включая:
1. реинжиниринг бизнес-процессов,
2. управление качеством (например, TQM, Шесть сигм),
3. операционное управление (например, MRP II, CIM, Kanban),
4. моделирование бизнес-процессов и
5. ИТ, воспринимающие процессы (например, рабочий поток и сервисно - ориентиро-
ванные архитектуры).
BPM получило широкое признание как основа современных подходов менеджмента, по-
скольку анализ бизнес-процессов доводит уровень понимания до самых корней организации.
Популярность и значимость BPM ставит вопрос об уровне, достигнутом различными органи-
зациями в области развития их BPM. В ряде подходов к управлению было предложено поня-
тие «зрелости» как способа оценки «состояния полноты, совершенства или готовности» или
«полноты или совершенства развития или роста» (Oxford University Press, 2004).
Данная глава описывает новую модель зрелости управления бизнес-процессами, которая
была разработана для оценки и повышения эффективности управления бизнес-процессами в
различных организациях.
Структура главы такова:
1. во втором7 разделе рассматривается ценность модели зрелости BPM, и то, как раз-
личные стадии могут быть представлены в рамках такой модели.
2. В третьем разделе представлена новая модель, разработанная специально для BPM, с
подробным описанием ее целей и базовой основы. Основная направленность этого раздела
— главные характеристики модели, которые имеют форму шести ключевых факторов успеха
и лежащих в их основе способностей.
3. В четвертом разделе рассмотрено возможное применение данной модели в организа-
ции с целью повышения операционной эффективности, а в пятом разделе приведено обосно-
вание и объяснение основ разработки модели.
4. В конце есть краткое заключение.
Зрелость управления бизнес-процессами
Управление бизнес-процессами — это сложная практика, которая во многих организа-
циях оказалась трудной для внедрения и доведения до высоких стадий зрелости. Это под-
тверждается исследованиями, показывающими, что:
 97% опрошенных организаций в Европе, считают BPM важным, и лишь
 3% начали практическую работу BPM, несмотря на признаваемую важность,
 73% опрошенных находятся на начальных стадиях принятия BPM [60].
Недавнее исследование руководителей ИТ, проведенное Гартнером [18], подтвердило
важность BPM, причем управление бизнес-процессами было названо самым высоко приори-
тетным вопросом на 2005 год. Поэтому для практиков BPM одно из опасений состоит в том,
что сложность проектов BPM может привести к невозможности получения организациями
желаемых выгод.
Модели зрелости используются:

7
А в первом что?
  как сравнительно-оценочная основа для усовершенствования (Фишер — Fisher, [17],
Хармон — Harmon, [30], Спаньи — Spanyi, [70]), а также
 с целью разработки осознанного подхода к повышению способностей организации в
конкретных областях (Полк — Paulk, [56]; Хейкс — Hakes, [22]; Ахерн — Ahern, [1]).
Такие модели разработаны, чтобы оценить зрелость (т.е. компетенции, способности,
уровень усложненности) в выбранной области на основе более или менее всестороннего
комплекса критериев. Поэтому модель зрелости BPM — это инструмент, который может по-
мочь организациям более успешно работать с BPM, получая более высокие показатели опе-
рационной и бизнес-эффективности и выгоды. К тому же растущее количество удачных
внедрений BPM будет способствовать позиционированию BPM как устойчивой практики
управления. В частности, модели зрелости можно применять как инструмент:
1. описания, дающий возможность оценить сильные и слабые стороны текущего состоя-
ния («как есть»);
2. предписания, дающий возможность разработать «дорожную карту» усовершенствова-
ний;
3. сравнения, устанавливающий точку отсчета при сравнении с отраслевыми стандарта-
ми и другими организациями.
В отличие от других существующих моделей рассматриваемая в последующих разделах
этой главы модель зрелости BPM была разработана для реализации всех трех целей.
Типология ступеней зрелости BPM
Полк и др. [56] подчеркивают, что повышение зрелости ведет к «росту способностей ор-
ганизации в области процессов». Поэтому неудивительно, что в последнее время был пред-
ложен ряд моделей для измерения зрелости различных граней BPM (Дейвенпорт —
Davenport, [12]).
Общей основой этих моделей стала модель зрелости способностей (CMM) с наиболее
распространенным способом оценки зрелости по пятибалльной шкале Ликерта, где «5» явля-
ется высшим уровнем. Одна из таких моделей на основе СММ среди прочих была развита
Хармоном [30] (см. также [29]). Аналогично Фишер [17] комбинировал пять «рычагов пере-
мен» с пятью состояниями зрелости. Смит и Фингар [69] утверждают, что модель зрелости
на основе CMM, которая постулирует наличие хорошо отлаженных и повторяемых процес-
сов, не может уловить необходимость инноваций бизнес-процессов. Впоследствии модели
зрелости BPM предлагались компаниями TeraQuest/Borland Software (Кертис — Curtis, [11])
и Группой управления бизнес-процессами (BPMG).
Помимо моделей зрелости, специально предназначенных для BPM, был представлен ряд
моделей, в которых изучались отдельные грани зрелости BPM. Примерами могут служить
модели зрелости стратегической согласованности Люфтмана (Luftman) [43] и ориентации
процессов Мак-Кормака (McCormack) [47] (последняя сосредоточена на эффективности
функционирования процессов).
Попытку классификации организаций по степени и развитости внедрения BPM пред-
приняли Притчард и Армистед (Pritchard, Armistead, [60]). Стремясь определить зрелость
программ реинжиниринга бизнес-процессов, Молл (Maull) [46] столкнулся с проблемами
применения объективных мер при измерении по двум показателям:
 объективному (время, численность группы и т.п.) и
 «взвешенной готовности к изменениям» [46].
Такой подход оказался слишком сложным для измерений. Поэтому был предпринят фе-
номенологический подход, оценивающий то, как сама организация воспринимает свою го-
товность к BPM, используя в качестве методических направлений объективные измерители.
Другой пример определения зрелости (или в данном случае «состояния процессов») дан у
ДеТоро и Мак-Кейба (DeToro, McCabe) [15], которые для оценки состояния процессов ис-
пользовали два измерения: эффективность и продуктивность.
 Сравнение на рис. 27.1 помогает прояснить комплексность и широту зрелости BPM. За-
мысел сравнить высокую и низкую ступень зрелости исходит из работы Полка [56], где сде-
лано такое сравнение, облегчающее понимание концепции зрелости процессов.
Предлагаемая модель берет на вооружение пять ступеней зрелости по CMM в попытке
разделить различные уровни сложности инициативы BPM.
Ступень 1. Начальная. Организации на ступени 1 либо вообще не предпринимают уси-
лий по внедрению BPM, либо эти усилия абсолютно не скоординированы и не структуриро-
ваны. Как правило, в таких организациях могут проявляться сочетания следующих характе-
ристик:
 не комплексные разовые (ad hoc)подходы;
 разрозненные попытки (ИТ или бизнес);
 необобщенные подходы к используемой методологии, инструментарию и методам;
 ограниченный объем инициатив BPM;
 минимальное привлечение персонала;
 слабое использование опыта BPM извне;
 высокий уровень вмешательства вручную и «обходных» путей.
Ступень 2. Повторяемая. Организации на ступени 2 прошли стадию приобретения пер-
вого опыта BPM, пытаются выстроить BPM-способности и расширить контингент сотрудни-
ков, которые видят организацию с точки зрения процессов. Обычно такая организация обла-
дает сочетанием следующих характеристик:
 первые документированные процессы;
 признание важности BPM;
 повышенное вовлечение исполнительного руководства и руководителей высшего
ранга;
 одна главная цель обследования BPM;
 интенсивное использование простого моделирования процессов с простым хранили-
щем данных;
 начальные попытки применения структурированной методологии и общих стандар-
тов;
 более интенсивное использование внешнего опыта BPM.
Ступень 3. Сформировавшаяся. Организации на ступени 3 обладают повышенным им-
пульсом в стремлении развивать BPM-способности и расширять число сотрудников, счита-
ющих организацию перспективной в области развития BPM. Как правило, такая организация
может характеризоваться следующими признаками:
 нацеленностью на ранние стадии процессного способа существования;
 использованием высокоразвитых инструментов (динамического моделирования, сер-
верных приложений, многочисленных и распределенных пользователей);
 сочетанием разных методов и инструментов процессного управления (перестройки
процессов, управления перечнем заданий рабочего потока и контроля рисков на основе про-
цессов);
 более интенсивным применением технологий внедрения и донесения BPM до пользо-
вателей (например, строение процессов доступно пользователям через внутренний сайт ор-
ганизации);
 всеобъемлющими и формальными сеансами обучения BPM;
 меньшей опорой на опыт извне.
 Ступень 4. Управляемая. Организации на ступени 4 пожинают плоды внедрения BPM,
твердо встроенного в стратегическую структуру организации. Как правило, такая организа-
ция обладает комбинацией следующих характеристик:
 сформирован Центр совершенствования управления процессами, который поддержи-
вает стандарты;
 исследование методов и технологий контроля бизнес-процессов;
 слияние ИТ- и бизнес-перспектив в управлении процессами (например, управление
рабочим потоком и раздельный учет затрат по типам деятельности);
 формально назначаемые должностные лица управления процессами;
 широкое принятие методик и технологий;
 задачи интегрированного управления процессами;
 процессная ориентация как обязательная составляющая проектов;
 постоянное расширение и укрепление инициатив (мероприятий/проектов) управления
процессами;
 минимальная опора на внешний опыт.
Ступень 5. Оптимизированная. В организации пятой ступени BPM является твердо
встроенным внутренним стержнем стратегического и оперативного управления. Как прави-
ло, в такой организации проявляются следующие признаки:
 управление процессами как часть деятельности менеджеров, их подотчетности и по-
казателей эффективности;
 широкое принятие и применение стандартных методов и технологий;
 единый общий для всей организации подход к управлению бизнес-процессами, кото-
рый включает клиентов, поставщиков, дистрибьюторов и другие заинтересованные стороны;
 сложившееся управление циклом существования процессов;
Центр совершенствования бизнес-процессов утрачивает свою значимость и размах, по-
скольку управление процессами становится просто образом ведения бизнеса.
Модель зрелости BPM
Наша модель зрелости управления бизнес-процессами (BPMM) более полно и современ-
но расширяет и уточняет предыдущие модели с учетом требований и сложности, обнару-
женных в бизнес-процессах.
Общие цели и основа. Разработка нашей модели основывалась на следующих соображе-
ниях:
1. мы хотели разработать модель на твердой теоретической основе, поэтому тщательно
изучили имевшиеся исследования BPM и разработки моделей уровня зрелости в разных об-
ластях знаний. На данную модель сильное влияние оказали обобщенные результаты прове-
денных исследований.
2. Мы хотели выработать широко принятый глобальный стандарт, а не представить
еще одну конкурирующую модель. Для этого мы обратились с предложением о сотрудниче-
стве к авторам и разработчикам предыдущих моделей уровня зрелости BPM. В течение ше-
сти месяцев мы провели серию исследований по методике Дельфи, дающих возможность
учесть вклад признанных лидеров мысли в области BPM. Каждое такое исследование отно-
силось к отдельному фактору модели и использовало метод сбалансированного опроса с
тремя или четырьмя раундами по каждому фактору, чтобы достичь консенсуса по несколь-
ким вопросам (Розманн и де Бруин, [63]). Получившаяся модель является результатом не
только слияния трех достаточно развитых моделей, но и учитывает вклад более двадцати ве-
дущих исследователей BPM.
3. Мы стремились разработать комплексную всестороннюю модель, которая охватывает
всю сферу BPM. Глубокое изучение работ по BPM обеспечило твердую теоретическую ос-
нову, а также всестороннее видение факторов успеха BPM, включая понимание препятствий
на пути успешного внедрения BPM и подробности различных подходов к реализации иници-
атив BPM. Таким образом, наша модель объединяет такие разнотипные элементы, как стра-
тегическое выстраивание, ИТ и культура.
4. Мы хотели добиться баланса теоретической строгости модели с ее высокой примени-
мостью. Как следствие, за последние два года модель применялась на различных стадиях
разработки в ряде организаций разных отраслей. Постоянный приток практических данных о
модели использовался для обеспечения отраслевой ориентации структуры и терминологии
во всей модели.
 5. Главная парадигма разработки заключалась в том, что модель должна поддерживать
индивидуальные информационные запросы различных групп заинтересованных лиц. В ре-
зультате в ней есть три уровня:
 шесть факторов успеха;
 области способностей в рамках каждого из этих шести факторов; и
 детализированные вопросы для измерения каждой области способностей.
6. По существу, эти уровни создают древовидную структуру, которую можно расширить
на основе требований к отчетности и анализу отдельного заинтересованного лица.
Результирующая модель является многомерной и включает несколько отличных друг от
друга составляющих:
1. факторы, стадии и объем (организационный объект и время).
2. В основе теоретической модели лежит предположение, что эти факторы (базирующи-
еся на важнейших выявленных факторах успеха BPM, препятствиях к успеху BPM и подхо-
дах к внедрению проектов BPM) являются независимыми переменными, а зависимая пере-
менная-функция — это успех BPM.
3. Еще одно предположение состоит в том, что более высокая степень зрелости по каж-
дому из этих факторов отразится в более высоких показателях успешности проекта BPM.
4. И, наконец, понятие «успеха процесса» необходимо перевести в адекватные, незави-
симые от BPM измерители успеха для всей организации — т.е. фактического успеха бизнеса
(рис. 27.2).

Есть две причины, по которым мы сосредоточили нашу модель на независимых факто-

рах:
1. они дают глубокое видение возможностей улучшения функционирования процессов,
а не способов его измерения.
2. уже имеется несколько моделей и решений для измерения эффективности функцио-
нирования процессов (например, измерение компании IDS). Краткий обзор «размерностей»
нашей модели, в том числе определение, происхождение и цель содержатся в табл. 27.1.

Таблица 27.1. Размерности модели BPMM

Размерность Определение Происхождение Цель

Фактор  Конкретный, Имеющиеся на сего-  Объединить

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

дельную характери- решающим факторам факторов, т.е. опре-

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

Стадия зрелости Заранее определен- Уровни и названия Численная оценка

ная стадия (от 1 — стадий перекликают- и суммирование
низшей до 5 — выс- ся с используемыми оценок последова-
шей) в СММ тельным сравни-
мым способом

Сфера охвата: структура Структурное подраз- Структурное подраз-  Подтвер-

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

Объем: время Момент времени, в Переменный пара-  Возмож-

который применяет- метр модели, выби- ность определить
Размерность Определение Происхождение Цель

ся модель раемый применяю- текущее состоя-

щей модель органи- ние и положение и
зацией формирование
внутренней точки
отсчета
 Обеспече-
ние возможности
применения моде-
ли в будущем для
оценки продвиже-
ния при долго-
срочном исследо-
вании

Проникновение Степень распростра- Основывается на Осознание, что

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

Профессионализм Воспринимаемый Концепция, основан- Осознание, что

уровень совершен- ная на понятиях эф- качество способ-
ства практики BPM в фективности и про- ностей в BPM за-
оцениваемом струк- дуктивности/ служивает при-
турном подразделе- результативности в знания
нии аналогичных моде-
лях (Де Торо и Мак-
Кейб, 1997)

Факторы считаются исходным измерением, поскольку представляют элементы внутри

организации, необходимые для успеха BPM. (Углубленный анализ подробностей модели см.
у Розманна и де Бруин в [62]).
Для нашего исследования в будущем важно будет определить соответствующие фоно-
вые факторы, например, процессно-ориентированная схема стимулирования может быть по-
казателем зрелости организации, но такую схему нельзя применить к государственным
учреждениям. Это приводит к важному соображению, что (очень вероятно) не существует
общего комплекса апробированных практических методов применения BPM, в равной сте-
пени пригодных для всех организаций. Поэтому мы определяем высшую ступень зрелости
(уровень 5) как наиболее тонкий и проработанный уровень применения BPM, который не
обязательно идентичен лучшему для организации уровню. Выбор наиболее отвечающего
организации уровня зрелости — это индивидуальная в каждом отдельном случае проблема,
решаемая исходя из ситуации, контекста, изначальных целей, связанных с этим ограничений,
возможных бизнес-обоснований и т.д.
Шесть факторов зрелости BPM
Обобщение работ по проблеме, совмещение трех существующих моделей зрелости BPM
и последующие исследования методом экспертных оценок привели к разработке нашей мо-
дели, в сердцевине которой лежит шесть факторов. Каждый фактор является важнейшим для
успеха управления бизнес-процессами, т.е. соответствующий компонент должен работать
правильно, чтобы внедрение BPM в организации продвигалось успешно. Далее каждый из
факторов был рассмотрен более детально по итогам экспертных оценок.
 Целью применения метода экспертных оценок было получение представления о совре-
менном видении глобальных вопросов BPM, которое трудно сформировать из имеющейся
литературы. Мы называем полученные подэлементы каждого фактора его областями спо-
собностей. В табл. 27.2 приведены демографические данные исследователей-участников
экспертных оценок.

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

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

Стратегическое согласование
Как часть нашей модели BPMM стратегическое согласование определяется как тесное
увязывание приоритетов организации и процессов предприятия, обеспечивающее постоян-
ные и действенные меры по повышению эффективности функционирования бизнеса. С по-
мощью нашего исследования методом экспертных оценок мы выделили пять основных обла-
стей, которые должны измеряться для оценки способностей стратегического согласования в
их связи с управлением бизнес-процессами. Последовательность представления этих пяти
областей отражает средний вес воспринимаемой важности, присвоенный участниками ис-
следования методом экспертных оценок:
1. вытекающий из стратегии план совершенствования процессов охватывает общий под-
ход организации к инициативе BPM. Этот план составляется, непосредственно исходя из
стратегии организации, и описывает, каким образом меры усовершенствования процессов
отвечают выстроенным в порядке стратегического приоритета целям. План совершенствова-
ния процессов дает информацию, связанную с целевыми показателями проекта совершен-
ствования процессов вместе с планируемыми процедурами обследования и мониторинга.
2. В разрезе BPM коренным элементом стратегического согласования является полное
двустороннее увязывание-согласование стратегии и бизнес-процессов. Дают ли бизнес-
процессы непосредственный вклад в стратегию, включает ли стратегия организации воз-
можности процессов? Например, знаем ли мы, какие процессы будут затронуты изменением
стратегии, а какие будут затруднять ее реализацию; разрабатывается ли стратегия и пере-
сматривается ли она в свете возможностей процессов; как следует распределить ограничен-
ные ресурсы; какие процессы лучше передать для исполнения в аутсорсинг или сторонним
организациям?
3. Архитектура процессов предприятия — это термин высшего уровня абстракции для
обозначения фактической иерархии процессов, обеспечивающих успешное развитие бизнеса.
Тщательно определенная архитектура процессов предприятия четко указывает главные биз-
нес-процессы организации, определяет конкретную для отрасли/компании цепочку создания
ценности, обозначает основные процессы, обеспечивающие функционирование этой цепоч-
ки, например подразделения финансов, персонала, ИТ. Тщательно разработанная архитекту-
ра процессов вытекает из трезвого понимания организационных структур с точки зрения
процессов. Помимо этого она служит общим фоном процессов и является отправной точкой
более детального анализа процессов.
4. Чтобы иметь возможность оценить фактическую эффективность процессов, важно
располагать детальным пониманием итоговых результатов/наработок процессов и связан-
ных с ними основных показателей эффективности (KPI). Иерархия ниспадающих процессно-
ориентированных и экономично измеряемых KPI — ценный источник преобразования стра-
тегических целей в конкретные задачи процессов, который способствует эффективному кон-
тролю процессов. Соответствующие KPI могут быть различного типа и характера, включая
финансовые, количественные, качественные или основанные на сроках. Они могут зависеть
от стратегических «приводов» конкретных процессов предприятия. Часто в равной степени
важно, но более трудно измерить KPI, связанные с такими характеристиками всего процесса
в целом, как гибкость или надежность.
5. Наконец, мы признаем, что стратегии обычно привязаны к отдельным лицам и влия-
тельным группам заинтересованных лиц. Поэтому необходимо оценивать, насколько хорошо
BPM увязано с реальными приоритетами ключевых клиентов и других заинтересованных
сторон: высшего руководства, акционеров, правительственных структур и т.п. Например,
на практике часто наблюдается, что замена высшего руководителя сильно сказывается на
общей популярности (или непопулярности) BPM, даже если официальная стратегия остается
неизменной. Среди прочего это также предусматривает определение успешности управления
процессами, имеющими точки соприкосновения с внешними сторонами, степени учета точек
зрения внешних сторон в строении процессов, а также влияния, которое оказывают внешние
заинтересованные стороны на разработку процессов.
Корпоративное управление BPM устанавливает адекватные и прозрачные процессы
подотчетности, принятия решений и вознаграждения, направляющие действия. В традициях
корпоративного и ИТ-руководства внимание в разрезе BPM сосредоточено на процессах
принятия решений и связанным с этим распределением ролей и ответственности:
 критически важным считается четкое определение и согласованное исполнение соот-
ветствующих процессов принятия решений BPM, которые направляют поведение как в про-
писанных (штатных), так и в непредвиденных ситуациях. Помимо того, кто может принять
какое решение, важна также быстрота принятия решений и способность влиять на выделение
ресурсов и реакцию организации на изменение процессов;
 другим стержневым элементом является распределение ролей и ответственности в
процессах. Под этим понимается весь диапазон функций, связанных с BPM: от действий ана-
литиков бизнес-процессов до решений хозяев бизнес-процессов и главных руководителей
процессов, и охватывает все соответствующие комитеты и подключаемые советы по приня-
тию решений. Обязанности и ответственность каждого лица нужно четко прописать и вы-
строить строгую структуру отчетности;
 должны существовать процессы, обеспечивающие прямую увязку метрик (стратеги-
ческих задач) и эффективности функционирования процессов. Хотя фактический результат
процесса измеряется и оценивается в рамках фактора стратегического согласования, проце-
дура сбора требуемых метрик и корреляции их с критериями эффективности рассматрива-
ется как часть корпоративного руководства BPM;
 стандарты управления процессами должны быть определены и оформлены докумен-
тально. Это включает координацию инициатив управления процессами по всей организации
и практические методики формирования и контроля таких компонентов управления процес-
сами, как показатели процессов, разрешение проблем, схемы вознаграждения и премирова-
ния и т.д.;
 механизмы воздействия на управление процессами как часть руководства BPM вклю-
чают регулярные циклы обследования с целью поддержания качества и актуализации прин-
ципов управления процессами, а также контроля соблюдения нормативных требований, свя-
занных со стандартами управления процессами. Такие механизмы контроля включают оцен-
ку степени соответствия стандартам руководства BPM с целью поощрения желаемого образа
поведения.
Методы в контексте BPM определяются как подходы и приемы, которые обеспечивают
и поддерживают согласованные действия процесса. К главным дискретным стадиям цикла
существования процесса могут применяться специальные методы. Эта характеристика, при-
сущая только факторам «методов» и «информационных технологий», приводит к областям,
отражающим стадии цикла существования процессов, а не конкретные параметры потенци-
альных методов или информационных технологий. Хотя, может статься, такое определение
зон способностей отличается от принятого для других факторов, важно отметить, что эти зо-
ны были установлены теми же экспертными оценками.
Преимущество сопоставления метода с конкретной стадией цикла существования про-
цесса состоит в возможности оценить методы, служащие конкретной цели, а не просто все
методы, связанные с управлением бизнес-процессами. Например, можно оценить конкрет-
ные методы, применяемые для разработки процессов, исключив методы, используемые для
усовершенствования процессов.
Такой тип анализа выглядит особенно полезным с учетом принятой практики разработ-
ки, маркетинга и внедрения методов (и ИТ), чтобы удовлетворить требования конкретной
стадии цикла существования процесса. Поэтому оценка зрелости методов сосредоточена на
конкретных запросах процесса и рассматривает такие элементы, как интеграция методов
цикла существования процессов друг с другом и с другими методами управления, поддержка
методов ИТ, а также сложность, пригодность, доступность и фактическое применение мето-
дов внутри каждой стадии:
 разработка и моделирование процессов связаны с методами, применяемыми для вы-
деления и концептуального осмысления действующих («как есть») и будущих («как будет»)
процессов. Стержнем таких методов являются приемы моделирования процессов;
 внедрение и исполнение процессов охватывает следующую стадию цикла существова-
ния процесса. Соответствующие методы помогают преобразовать модели процессов в ис-
полняемые спецификации бизнес-процессов. Методы, связанные с распространением этих
моделей, и методы эскалирования способствуют исполнению процессов;
 измерение и контроль в цикле существования процесса связана с методами сбора свя-
занных с процессами данных. Эти данные могут относиться к контролю процессов (напри-
мер, риски или ошибки) или могут быть показателями эффективности процессов;
 инновации и усовершенствование процессов включает все методы, которые содей-
ствуют разработке улучшенных и новаторских процессов. Сюда относятся такие подходы,
как инновации процессов, шесть сигм и т.д.;
 управления программами и проектами процессов оценивает подходы, которые при-
меняются для общего управления программой или проектами BPM, включая управление из-
менениями процессов.
 Информационные технологии (ИТ) обозначают программное и аппаратное обеспече-
ние, а также системы управления информацией, которые обеспечивают и поддерживают де-
ятельность, связанную с процессами. Оценка зон способностей ИТ структурирована анало-
гично методам, и сначала связана со стадиями цикла существования процессов. Компоненты
ИТ сосредоточены на конкретных требованиях каждой стадии цикла существования процес-
са и оцениваются с точек зрения настраиваемости, автоматизируемости и интеграции с соот-
ветствующими решениями ИТ, а также на основе более общих соображений сложности
устройства, пригодности, доступности и пользования каждой ИТ на каждой стадии:
 разработка и моделирование процессов охватывают ИТ, которые позволяют выво-
дить модели процессов напрямую из файлов регистрации, а также общую инструментальную
поддержку моделирования и анализа бизнес-процессов (например, анимация процессов,
имитационное моделирование);
 внедрение и исполнение процессов сосредоточено на автоматизированном преобразо-
вании моделей процессов в исполняемые спецификации и последующем исполнении про-
цессов на основе рабочего потока. Сюда также относятся такие решения, как системы управ-
ления документацией или сервисно-ориентированные архитектуры. Вся эта категория ПО
часто называется «процессно-контекстными информационными системами»;
 измерение и контроль процессами облегчают (полу-) автоматическое управление эс-
калированием процессов, обработку исключений, поиск и обработку данных рабочего пото-
ка, визуальное представление показателей эффективности (например, экран инструменталь-
ной панели) и контроллинг на основе регистрационных файлов процессов;
 инноваций и усовершенствование процессов обеспечивают автоматизированную под-
держку создания усовершенствованных бизнес-процессов. Это могут быть решения, дающие
самонастраивающийся (т.е. самообучающийся) инструментарий, который непрерывно под-
страивает бизнес-процессы на основе изменений контекста;
 управления программами и проектами процессов облегчают общее управление про-
граммой и проектами. Они весьма важны, но обычно менее BPM-специфичны.
Люди. В то время как фактор информационных технологий охватывает связанные с ИТ
ресурсы, фактор «людей» включает человеческие ресурсы. Он определяется как отдельные
лица и группы, которые постоянно расширяют и применяют свои знания процессов и навыки
работы с ними для повышения эффективности бизнеса. Сторона этого фактора, которая со-
средоточена на знаниях и умениях людей, участвующих в инициативе BPM, может считаться
«жесткой», в то время как следующая зона («культура») может рассматриваться как «мяг-
кая» и охватывает поведение и занимаемые позиции, ведущие к общему признанию BPM
внутри организации:
 профессиональные знания и умения процессов нацелены на комплексность и глубину
способностей привлеченных заинтересованных лиц в свете требований, сформулированных
в ролевой инструкции их должности или роли (например, аналитик бизнес-процессов, хозя-
ин процесса);
 управление процессными знаниями укрепляют и объединяют глубину познаний прин-
ципов и практики BPM. Это оценка уровня понимания BPM, включая знания методов управ-
ления процессами и ИТ, а также влияния этих элементов на результаты процессов предприя-
тия;
 обучение процессам и образование определяет настрой организации на постоянное
развитие и поддержание соответствующих навыков и знаний процессов. Такая оценка охва-
тывает наличие, степень, пригодность и фактический успех (измеряемый уровнем подготов-
ки) программ образования. Другие элементы относятся к квалификации учителей BPM и
программам аттестации/сертификации BPM;
 общая работа и общение в процессах связано с совместными действиями отдельных
лиц и групп в достижении желаемых результатов процессов. Это предусматривает соответ-
ствующий оценочный анализ моделей общения между заинтересованными сторонами и спо-
собов выделения, изучения и распространения знаний, связанных с процессами;
 главы / лидеры управления процессами - последняя зона способностей. Оценка зрело-
сти в данном случае измеряет готовность руководителей вести за собой, принимать обяза-
тельства и отвечать за бизнес-процессы. Среди прочего здесь также должно отражаться,
насколько желаемые навыки лидерства в процессах и стили руководства используются на
практике.
 Культура — шестой и последний фактор — это коллективные ценности и представле-
ния, которые формируют отношение к процессам и модели поведения для повышения эф-
фективности бизнеса. В исследовании по методике экспертных оценок было удивительно
наблюдать, что консенсус и взаимопонимание по областям способностей в этом факторе бы-
ли достигнуты гораздо легче и при значительно меньших спорах, чем в предшествующих
исследованиях. Возможно, этот факт оказался результатом того, что «культура» была одним
из последних предметов в серии исследований, но исследования фактора «люди» проводи-
лось одновременно, и похожего факта при этом не отмечалось:
 восприимчивость изменений процессов относится к общей склонности организации
воспринимать изменения процессов, ее расположенности принимать такие изменения и
адаптации, способности процессов без проблем пересекать функциональные границы, и воз-
можности персонала действовать в высших интересах процессов;
 ценности процессов и убеждения / воззрения изучают процессное мышление в орга-
низации в широком смысле, т.е. считают ли сотрудники, что процессы — это способ полу-
чать результат, сделать дело. Данная зона нацелена на общепринятые представления о роли
BPM и его выгодах. Среди них долговечность BPM, выражаемая глубиной и широтой убеж-
денности в его необходимости;
 занимаемая позиция в отношении процессов и поведение людей, вовлеченных в BPM,
и тех, кого оно затрагивает, — это еще один оцениваемый элемент в факторе культуры. Сре-
ди прочего, сюда включается готовность поставить под сомнение существующий порядок в
свете потенциального усовершенствования процессов и фактических моделей поведения,
связанных с процессами;
 внимание лидеров / руководства к процессам охватывает твердость убежденности и
внимания к процессам и управлению процессами, проявляемые высшими руководителями,
степень внимания к процессам на всех уровнях, а также качество лидерства;
 социальные сети управления процессами включают существование и влияние сооб-
ществ практического применения BPM, использование методов социальных сетей, призна-
ние и применение неформальных сетей общения BPM.
Применение модели BPMM
Модель зрелости BPM (BPMM) может применяться в организации различными спосо-
бами, в зависимости от нужной широты и глубины применения.
Широта относится к анализируемой структуре, выбранной для оценки. Анализируемая
структура может быть (в самом общем случае) всей организацией или отдельными направ-
лениями бизнеса. Модель может применяться отдельно к нескольким анализируемым струк-
турам, что дает ценные данные для сравнения внутри организации.
Для каждой анализируемой структуры модель используется двумя способами: на уровне
факторов и на уровне способностей. Это представляет глубину ее применения.
Применение на уровне факторов дает возможность выполнить общий анализ с сопо-
ставлением результатов по шести факторам, содержащимся в модели, т.е. стратегическому
согласованию, корпоративному руководству, методам, информационным технологиям, лю-
дям и культуре. Как правило, такой уровень анализа достигается специалистами BPMM пу-
тем собеседований с глазу на глаз с ключевыми руководителями, что дает дополняющие
друг друга видения инициатив BPM в организации. После этого специалисты BPMM анали-
зируют итоги собеседований, делают подробную презентацию и отчет для организации. Та-
кой уровень анализа полезен для получения грубого представления о «текущем» состоянии
BPM с точки зрения руководства и является удобной отправной точкой для понимания
сложности и проработанности действий организаций в BPM.
Применение модели на уровне способностей дает более глубокое представление о теку-
щем состоянии BPM за счет дополнительного анализа пяти зон способностей, определенных
для каждого из шести факторов. Помимо собеседований с руководством этот уровень анали-
за предусматривает глубокие обсуждения на совещаниях с соответствующими сотрудника-
ми, имеющими специальные знания в области BPM. Помимо более подробной картины те-
кущего состояния работ по BPM, этот уровень анализа позволяет сформулировать стратегию
на будущее, нацеленную на конкретные аспекты BPM. Еще одно преимущество данного
уровня анализа состоит в сравнении представления о BPM руководства и рядовых сотрудни-
ков. Более того, оценка зрелости BPM на уровне способностей дополняется анализом свя-
занной с BPM документации (например, моделей процессов, должностных инструкций,
определений показателей KPI процессов).
Предполагается, что дальнейшие версии модели будут включать элемент самооценки,
позволяющий организации получить оценку зрелости с ограничениями без необходимости
помощи BPMM-профессионалов извне, а также возможность проведения полномасштабной
всесторонней оценки сертифицированными оценщиками.
Смежные труды. Более 150 моделей уже разработаны для измерения зрелости способ-
ностей ИТ-сервисов, стратегического согласования, управления инновациями, программами,
архитектуры предприятия и управления знаниями. Многие из этих моделей предназначены
для оценки зрелости избранной сферы на основе более или менее комплексного набора кри-
териев.
В отличие от модели CMM, которая стала стандартом соответствия в сфере разработки
ПО (Мутафелия и Стромберг — Mutafelija, Stromberg, [49]), большинство остальных моде-
лей просто позволяют определить место анализируемой структуры на заранее заданной шка-
ле. Недостатками имеющихся моделей являются упрощенная концентрация на только одно
измерение зрелости BPM и нехватка фактических применений этих моделей. Более того,
многие существующие модели BPM не всегда четко различают оценку зрелости самого биз-
нес-процесса (измеренную по его показателям эффективности) и зрелости управления биз-
нес-процессами. Еще один недостаток многих имеющихся моделей — отсутствие строгости
в процессе разработки модели, ограниченность охвата и глубины отдельных граней BPM, их
своеобразный типаж из-за отсутствия корней в смежных работах, отсутствие учета нужных
заинтересованных сторон, нехватка эмпирических испытаний моделей и недостаточная глу-
бина уровней оценки.
Предлагаемая модель BPMM устраняет эти недостатки, сочетая строгость теоретической
базы с разнообразными практическими применениями во время разработки, что обеспечива-
ет включение в результирующую модель специфических требований BPM практичным и по-
лезным образом.
Заключение
В этой главе кратко и избирательно описана структура и компоненты, образующие со-
временную комплексную модель зрелости BPM. Фактическая оценка, выведенная при при-
менении этой модели, может быть получена на различных уровнях. Мы рекомендуем прово-
дить такую оценку более подробно на один уровень ниже зон способностей. Весь комплекс
оценки основан на анкете, частично структурированных собеседованиях с ключевыми заин-
тересованными лицами BPM и оценке документации, относящейся к BPM (должностных ин-
струкций и схем стимулирования, привязанных к процессам, а также моделей процессов).
Триангуляция этих трех источников информации дает окончательный рейтинг оценки. По
аналогии с исходной моделью CMM для каждого из шести факторов рассчитывается отдель-
ная оценка (по пятибалльной шкале). Это дает организации картину ее инициатив BPM и
помогает выявить болевые точки для принятия немедленных мер, повышающих зрелость
BPM. Соответствующий полуавтоматический инструмент обеспечивает сбор, анализ и пред-
ставление информации.
В данный момент мы проводим ряд конкретных исследований организаций в Европе,
Америке и Австралии, чтобы глубже понять требования, относящиеся к оценке зрелости
BPM, и получить дальнейший отклик о пригодности нашей модели.

Глава 28. Внедрение BPM в организацию

Эта глава посвящена тому, каким образом и где следует внедрять BPM в организации. В
предыдущих главах мы концентрировались на процессах с точки зрения проекта или про-
граммы. Здесь фокус смещается на постоянно действующее управление процессами и их
поддержку с точки зрения организации.
Зачем нужна особая структура BPM в организации?!
Улучшение процессов и получение результатов является не окончанием, а лишь началом
управления бизнес-процессами. В предыдущих главах показано, как обеспечить существова-
ние культуры постоянного усовершенствования и мониторинга процессов, но этого недоста-
точно. Организация должна иметь необходимую структуру, обеспечивающую понимание
выгод BPM и их постоянство. Процессно-ориентированные организации понимают, что им
нужна соответствующая структура. Наш опыт показывает, что хотя подразделение BPM мо-
жет начать работу с проекта, необходимо долговременное и структурное решение, чтобы
обеспечить постоянство усовершенствований.
С точки зрения организационной структуры большинство компаний, которые взялись
за управление процессами, встали на путь гибридного подхода. Функциональная мешанина
прошлого не исчезает за один день. Менеджеры направлений бизнеса по-прежнему управля-
ют работой, но для важных процессов, особенно пересекающих внутренние границы орга-
низаций, обычно назначается хозяин процесса, отвечающий за функционирование процесса в
каждом из различных бизнес-подразделений.
Майерс (Miers) [48]:
Внедрение BPM в организации требует:
 четкого организационного позиционирования BPM с ясным распределением ролей,
обязанностей и уровней полномочий;
 структуры, которая может развиваться вместе с растущим значением BPM в органи-
зации.
Мы воспользуемся уровнями зрелости BPM из главы 27, чтобы указать различные пути
встраивания BPM в структуру организации, и выделим фазы, показанные в табл. 28.1.
Таблица 28.1. Встраивание BPM в структуру организации
Уровень Ступень зрелости Положение внутри организации

1. Начальная Проект BPM

2. Повторяемая Программа BPM

3. Сформированная Центр совершенствования бизнес - процес-

сов

4. Управляемая и оптимизируемая Участие на уровне правления организации

и назначение руководителя процессов

Следует подчеркнуть, что специализированный проект BPM, программа BPM, Центр со-
вершенствования бизнес-процессов (Center of Business Projects Elaborations - CBPE) и глав-
ный руководитель процессов (Chief Process Officer - CPO) фундаментально различаются, и у
каждого из них свои задачи, структуры и положение внутри организации.
В табл. 28.2 показаны перечисленные выше фазы и роли на каждом уровне. Также дается
количество работников, занятых полный рабочий день (full time employee - FTE), которое
может потребоваться для каждой фазы. Эти примерные данные численности персонала бу-
дут, очевидно, зависеть от размера организации и масштаба внедрения BPM.
Таблица 28.2. Организационная структура BPM

Роль Проект BPM (уро- Программа BPM Центр совершен- Главный руководи-
вень 1) (уровень 2) ствования бизнес- тель процессов
процессов (уровень (CPO - уровень 4)
3)
CPO 1,0 FTE
Менеджер Центра 1,0 FTE 1,0 FTE
совершенствования
бизнес-процессов
Менеджер про- 1,0 FTE По необходимости По необходимости
граммы BPM
Менеджер проекта 0,5 - 1,0 FTE По необходимости По необходимости По необходимости
BPM
Архитектор процес- 0,5 - 1,0 FTE 1,0 - 2,0 FTE 1,0 - 2,0 FTE 1,0 - 2,0 FTE
сов
Инженер процессов По необходимости По необходимости По необходимости По необходимости
Специалист по мо- 1,0 - 2,0 FTE 1,0 - 3,0 FTE 2,0 - 4,0 FTE 2,0 - 4,0 FTE
делированию про-
цессов
Консультант BPM 0,5 - 2,0 FTE 1,0 - 3,0 FTE 2,0 – 4,0 FTE 2,0 – 4,0 FTE
Администратор По необходимости 1,0 FTE 1,0 FTE 1,0 FTE
инструмента моде-
лирования и управ-
ления процессами
Тренер BPM 0,3 - 0,6 FTE 0,6 - 1,0 FTE 1,0 - 2,0 FTE 1,0 - 2,0 FTE

Уровень 1. Цель проекта BPM (начальный)

Чтобы добиться достижения целей проекта BPM обычно применяется сценарий «пилот-
ный проект», который формируется согласно объему проекта BPM.
Вызовы - на данном уровне важно решить следующие проблемы:
 проект должен формировать осознание BPM, чтобы обеспечить твердую привержен-
ность и достаточную поддержку. Важно найти баланс между общими выгодами BPM и кон-
кретными результатами самого проекта;
 проект не должен долго задерживаться на формировании осознания BPM, поскольку
все участники проекта должны помнить, что об их усилиях будут большей частью судить по
достижению целей проекта, а не по осознанию BPM, что лежит вне рамок проекта. Проект
должен стать лучшей иллюстрацией бизнес-выгод BPM. Лучший способ убедить в пользе
BPM — НЕ теориями или примерами из учебников, а достижением результатов внутри са-
мой организации;
 проект должен быть согласован с другими инициативами, чтобы выявить синергию
усовершенствования процессов. Это поможет в повышении прозрачности и принятии BPM
во всей организации;
 должно обеспечиваться достаточное распространение информации в начале проекта.
Слишком часто информация начинает поступать уже в самом конце реализации проекта, ко-
гда уровень уверенности в успехе выше, что часто оказывается слишком мало и слишком
поздно.
Состав. Структура проекта BPM должна, по крайней мере, включать:
 менеджера проекта BPM, ответственного за достижение установленных целей проек-
та. Как указывалось выше, менеджер проекта BPM должен быть из бизнес-подразделения, а
не извне организации и не из подразделения ИТ;
 архитектора процессов (возможно, с частичной занятостью в проекте), чьи основные
обязанности — обеспечить согласование проекта и архитектуры процессов с общей архитек-
турой предприятия, а также информирование нужных людей внутри организации и их во-
влечение в реализацию архитектуры процессов;
 консультанта BPM, помогающего выявить и реализовать выгоды, которые могут быть
получены посредством BPM, включая новые возможности через изменения процессов, и
осуществляющего роль «поводыря» для соответствующих лиц в достижении выгод;
 специалистов, моделирующих процессы, чьи основные обязанности включают моде-
лирование процессов на этапах понимания и инноваций;
 бизнес-тренера (с частичной занятостью), который проводит общее обучение BPM.
К проекту могут также привлекаться следующие лица:
 инженер процессов, который может привлекаться в случае применения автоматизи-
рованного решения. Если организация реализует свои первые проекты BPM, инженер про-
цессов должен обеспечить пригодность технического решения для инфраструктуры органи-
зации. Это может оказаться серьезным вызовом, поскольку часто включает различные си-
стемы, интерфейсы и версии ПО;
 администратор инструмента моделирования и управления, который должен обеспе-
чить необходимые функциональные возможности моделирования и управления процессами.
Большинство участников проекта будут прикомандированы к нему на срок его действия.
В задачу менеджера проекта BPM входит обеспечение высокой мотивированности группы,
ее эффективности и продуктивности, готовности ответить на более серьезные вызовы. В
Приложении С подробно расписаны роли и обязанности членов группы проекта.
Положение внутри организации. Место проекта внутри организации должно соотно-
ситься с бизнес-подразделением, чьи процессы планируется усовершенствовать. Спонсор
проекта должен активно и деятельно участвовать в проекте и быть его твердым привержен-
цем, нацеленным на достижение конечных результатов. Он должен занимать высокую долж-
ность в своем подразделении.
Поддержка извне. Обучение и наставничество — самые общие формы внешней под-
держки, особенно при первом опыте внедрения проекта BPM на основе общей схемы.
Уровень 2. Цель программы BPM (повторяемый)
 На уровне 2 у организации уже есть опыт нескольких успешно реализованных проектов
BPM, и/или в ней запущена программа BPM, включающая несколько проектов. Цель про-
граммы BPM — достижение результатов по нескольким проектам, подразделениям, систе-
мам, продуктам и услугам.
Вызовы - на уровне 2 важно решить следующие проблемы:
 программа BPM должна поддерживать баланс между обеспечением успеха отдельных
проектов и стремлением следовать формирующимся стандартам и методам организации. Та-
кие стандарты чрезвычайно важны для организации по мере появления новых проектов и
вовлечения в них людей: если не получится обеспечить следование стандартам в ходе про-
граммы, то точно не удастся и в организации в целом;
 программа BPM может набирать ход, используя опыт и уроки, извлеченные из
предыдущих проектов, и применяя усовершенствованные методики. Программа BPM долж-
на доказать, что первый успех (успехи) можно повторить и расширить;
 для организации важно понимать, что программа BPM — это не просто проект BPM
большего масштаба и объема.
Состав. Помимо основных участников проекта BPM, в программе должны принимать
участие следующие лица:
 менеджер программы BPM, на котором лежит ответственность за достижение целей
(или их превышение) всех проектов BPM, находящихся под его контролем. Менеджер про-
граммы BPM не обязательно является менеджером проекта на предыдущем этапе/стадии,
поскольку требуемые профессиональные умения и навыки всякий раз разные;
 архитектор процессов, от которого требуется обеспечить соответствие всех проектов
и инициатив согласованным стандартам, чтобы не изобретать колесо. Более того, архитектор
процессов должен контактировать с другими архитекторами организации, устанавливая об-
раз действий (modus operandi);
 специалист по моделированию процессов или контролер качества процессов, который
должен направлять работу различных лиц, моделирующих процессы в проектах BPM, и про-
водить обучение в ходе работы. Это лицо может также оказывать помощь в некоторых ас-
пектах моделирования, особенно при формировании первоначального перечня сквозных
процессов;
 консультант BPM, который консультирует по вопросам выгод, извлекаемых из ис-
пользования опыта различных проектов BPM и внутреннего управленческого учета для биз-
неса;
 администратор инструментов моделирования и управления процессами: в программе
BPM весьма вероятно будет (и настоятельно рекомендуется иметь) инструмент моделирова-
ния и управления процессами, в противном случае управление моделями станет чрезвычайно
затруднительным (или даже невозможным). Администратор обеспечивает поддержание ми-
нимального комплекса стандартов, иначе инструментарий может стать неуправляемым.
К программе могут также привлекаться следующие лица:
 один или нескольких специальных менеджеров проектов BPM, которые будут отве-
чать за более сложные проекты, обучение и поддержку младших менеджеров проектов. Та-
кие менеджеры могут привлекаться при наличии трудностей в проектах;
 инженер (инженеры) проектов, которые оказывают содействие и повторно применяют
различные наработки данного проекта в других проектах (BPM или не связанных с BPM);
 куратор BPM, который с расширением объема и вовлечением все большего числа лю-
дей может формировать программы обучения BPM и, возможно, осуществлять внутреннее
обучение.
Положение внутри организации. Менеджер программы BPM должен иметь тесные связи
с главными заинтересованными сторонами различных проектов. В долгосрочных програм-
мах особое внимание нужно уделить общению и информированию различных заинтересо-
ванных лиц, бизнеса и членов групп проектов. Следует также подумать о названии программ
для использования его во внутреннем и внешнем маркетинге.
Поддержка извне. Если зрелость организации в области BPM недостаточна, на этой ста-
дии внешняя поддержка играет важнейшую роль для принятия правильного подхода. На
уровне 2 BPM находится на взлете, поэтому фальстарт приведет к огромным затратам энер-
гии, времени и денег. Внешние эксперты привнесут опыт, почерпнутый в других ситуациях.
Уровень 3. Центр совершенствования бизнес-процессов (сформированный)
 На данной стадии управление процессами набирает ход.
Цель. К этому моменту организация успешно реализовала несколько крупных проек-
тов/программ, и BPM набрало ход и импульс. Теперь организация намерена институцио-
нально закрепить свой профессионализм и опыт BPM, организовав Центр совершенствова-
ния бизнес-процессов (CBPE). Этот центр сводит вместе людей с различным опытом и про-
фессиональными навыками для решения сложных проблем. Это продвигает традиционную
концепцию управления проектами далеко за пределы основной задачи — технической реа-
лизации проекта. Очевидно, что CBPE требует широкого спектра профессиональных качеств
для реализации проектов BPM по нескольким фазам цикла существования: от зарождения до
подведения итогов (через разработку и реализацию).
CBPE нацелен на содействие сотрудничеству между бизнесом и ИТ, наделяя бизнес
большей ответственностью за реализацию автоматизированных и неавтоматизированных
решений BPM. Центр фактически объединяет ресурсы с целью оказания помощи самым раз-
нообразным бизнес-подразделениям в разработке, реализации и/или управлении проектами
самосовершенствования BPM.
CBPE — это группа людей, которые являются специалистами организации по реализа-
ции BPM. Они не осуществляют все работы, укладывающиеся в проект, поскольку не это
дает долговременные и устойчивые результаты. Скорее CBPE — это централизованный ор-
ган, члены которого должны обеспечивать профессионализм, дающий возможность соответ-
ствующим бизнес-подразделениям добиваться успеха в реализации BPM.
Особая деятельность, осуществляемая CBPE:
 установление стандартов процессов, что может включать методологию, измерение
показателей эффективности процессов, контроль качества процессов, инструментарий и ме-
тодики;
 предоставление бизнесу высокопрофессиональных ресурсов в плане процессов;
 постоянное внедрение в организации BPM, назначая нужных хозяев и менеджеров
процессов;
 сохранение ведущей роли в управлении бизнес-процессами.
Вызовы. На уровне 3 важно решить следующие проблемы:
 обеспечение помощи бизнес-подразделениям в достижении их целей и решении сто-
ящих перед ними задач. Поэтому CBPE не должен сильно разрастаться или излишне глубоко
погружаться в проект BPM, т.е. должен быть компактным — скорее всего, не более шести-
восьми человек;
 указывать направление всем, кто хочет мыслить и работать более процессно-
ориентированно, наставляя людей, задумывающих инициативы в сфере процессов. CBPE
должен сформировать процессное сообщество внутри организации, давая возможность со-
трудникам из разных бизнес-подразделений обмениваться опытом и практическими нара-
ботками;
 подыскать правильного главу CBPE. Он должен быть деятелен, но терпелив (напри-
мер, бизнес-подразделение нужно подвести к увлеченности BPM, потому что именно этому
подразделению придется выполнить основную работу). Менеджер CBPE должен видеть пер-
спективу Центра, организации и увязывать их с повседневной работой. Естественное реше-
ние — назначить главой Центра успешного менеджера программы BPM, но нужно понимать
существенную разницу этих двух ролей;
 особенно важно финансирование СBPE. В идеале часть выгод, получаемых бизнес-
подразделениями в результате BPM, должна трансформироваться в денежные вложения в
CBPE, чтобы продолжать «миссионерскую» деятельность Центра. Существенно, что финан-
сирование обеспечивается бизнес-подразделениями, т.к. это делает Центр более отзывчивым
на запросы. Можно взимать плату за услуги CBPE или выделять средства из бюджета раз-
личных бизнес-подразделений, проектов и программ. Если средства выделяются непосред-
ственно исполнительным руководством, нужно, чтобы CBPE ставил цели вместе с бизнесом,
сохраняя ориентацию Центра на запросы бизнес-подразделений;
 необходимо, чтобы CBPE сохранял в фокусе внимания результаты, которых должны
достичь бизнес-подразделения. Это будет лучшей рекламой для CBPE. Критерием успешной
работы Центра не должно быть количество обученных сотрудников, используемых лицензий
(на инструменты моделирования и управления процессами) и созданных моделей процессов;
  CBPE может строиться на основе конкретного инструмента моделирования и управ-
ления процессами. Но это не идеальный вариант. В таком случае CBPE недостаточно просто
обучить персонал применению инструмента моделирования и управления процессами, а за-
тем отпустить людей «возиться» с проектами. CBPE должен обеспечить понимание всеми
бизнес-подразделениями, в чем состоят выгоды BPM, как их определить, и как этому помо-
гает инструментарий. Нельзя встать на позицию «наш инструмент — решение; в чем ваши
проблемы?». Лучший способ убедить в полезности CBPE — прислушиваться к требованиям
и проблемам бизнеса и рекомендовать наиболее подходящее решение, даже если оно не яв-
ляется инструментом самого Центра;
 общение и информирование — далеко не последний по важности фактор для форми-
рования CBPE и обеспечения возможности продолжать увязывать свои услуги с изменяю-
щимися запросами и проблемами внутри организации. Общение дает понимание выгод, ко-
торые CBPE может дать каждому сотруднику и организации в целом.
Состав. В CBPE должен быть (по крайней мере) следующий штат:
 менеджер Центра, основная обязанность которого — обеспечить способность Центра
оказывать помощь бизнес-подразделениям организации в достижении результатов. Важно,
чтобы этот менеджер мог мотивировать и направлять персонал, был способен общаться и
работать с другими бизнес-менеджерами и исполнительным руководством;
 архитектор(ы) процессов, обеспечивающие формулирование, обновление и примене-
ние архитектуры процессов. Они также плотно участвуют в формулировании и реализации
архитектуры предприятия;
 консультант/менеджер клиентов BPM, который работает вместе с бизнес-
подразделениями для выявления возможностей усовершенствования бизнес-процессов и
управления процессами внутри организации и координирует оказание помощи СBPE. Кон-
сультант должен первым обсуждать с бизнес-подразделениями возможности BPM и роль,
которую будет играть CBPE. В организациях, где CBPE взимает плату со своих клиентов,
консультант также является менеджером клиентов;
 контролеры качества процессов/ведущие специалисты моделирования процессов, от
которых требуется обеспечить соответствие различных проектов и инициатив нужным (ми-
нимальным) стандартам, чтобы всякий раз не изобретать колесо. Эти профессионалы долж-
ны направлять работу обычных специалистов моделирования процессов в проектах BPM и
обеспечивать обучение на местах. Они могут также помочь при моделировании, особенно
при формировании структуры проекта на начальной стадии;
 администратор инструмента моделирования и управления процессами: CBPE требу-
ется иметь средство моделирования и управления процессами. Администратор обеспечивает
соблюдение минимального комплекса стандартов;
 тренер BPM, отвечающий за подготовку и организацию обучения. С ростом числа
обучаемых он также формирует программы обучения с расчетом на конкретные требования
организации, вместо стандартного курса подготовки.
По выбору в CBPE может быть менеджер высокого ранга проекта BPM, помогающий
отдельным менеджерам проектов BPM, участвующий в оживлении проектов BPM (которые
нуждаются в помощи) и поддерживающий менеджера программы BPM. Этот человек обыч-
но привлекается на начальной стадии проекта, а затем ведет мониторинг его продвижения.
CBPE должен обеспечить наличие специальных инженеров процессов в подразделении
ИТ, если организация применяет автоматизированное решение. CBPE должен сопротивлять-
ся соблазну иметь своих инженеров, поскольку это ведет к субоптимизации и фрагментации
знаний и опыта ИТ.
Положение внутри организации. Как уже говорилось, CBPE существует для содействия
и поддержки деятельности в рамках различных проектов и программ BPM. Поэтому CBPE
должен находиться в центральном месте организации, предпочтительно на корпоративном
уровне. Он не должен подчиняться ИТ, поскольку BPM — это работа, связанная с бизнесом.
Уровень 4. Главный руководитель процессов (управляемый и оптимизируемый)
Управление процессами имеет стратегическое значение. Чтобы процессы получили мак-
симум внимания и обязательств исполнительного руководства, решающим шагом является
назначение специального ответственного лица — главного руководителя процессов (CPO).
Цель. CPO отвечает за формирование процессов таким образом, чтобы они эффективно и
продуктивно вносили вклад в достижение целей организации. Этого можно добиться, если
архитектура процессов организации прочно укоренилась в общей архитектуре предприятия,
все процессы учитываются при любом крупном изменении или инициативе внутри компа-
нии, а CBPE заслужил уважение за свой вклад в бизнес.
CPO будет отвечать за координацию стратегий организации в различных областях и их
согласование со стратегиями конкретных процессов. Здесь есть следующие аспекты:
 обслуживание клиентов;
 разработка новых продуктов;
 стратегия закупок;
 стратегия выполнения заказов;
 стратегия людских ресурсов и обучения;
 стратегия учета и финансов;
 технологическая стратегия.
В сферу ответственности CPO входят все сквозные процессы внутри организации, кото-
рые могут расширяться до процессов, связывающих организацию с клиентами, поставщика-
ми и партнерами. Сюда также относятся процессы, связанные с ИТ. Как сказано выше, ИТ
направлены на поддержку бизнес-процессов, а разделение этих двух областей ведет к субо-
птимизации.
CPO отвечает за:
 сквозные процессы в организации;
 достижение целей процессов по всей организации, обеспечение плавного потока дан-
ных, документации и информации между подпроцессами;
 сохранение направленности на клиента. Должна вестись постоянная работа, направ-
ленная на то, чтобы процессы в целом функционировали к удовлетворению клиента;
 обеспечение решений проблем, устранения разрывов или нестыковок, возникающих
при пересечении процессами границ подразделений, к удовлетворению всех заинтересован-
ных сторон;
 планирование, управление и организацию процессов в целом;
 обеспечение определения, мониторинга и поддержания соответствующих
мер/показателей процессов;
 формирование и поддержание общей схемы проекта BPM или методологии во всей
организации;
 подпитку постоянно действующих текущих программ усовершенствования бизнес-
процессов;
 отлаженную работу группы Центра совершенствования бизнес-процессов;
 установление и поддержание взаимоотношений с поставщиками решений BPM;
 текущее управление знаниями BPM организации;
 общее управление качеством.
Основные действия хозяина процесса:
 документирование процессов. Документирование соответствующих процессов долж-
но быть правильным, актуальным и простым в использовании. Более того, хозяин процесса
должен обеспечить соответствие документации всем надлежащим стандартам и требованиям
(например, соблюдение требований нормативных актов);
 совершенствование процессов. Хозяин процесса является узловым пунктом, которому
поступают предложения по усовершенствованиям процессов, и отвечает за решения, управ-
ление изменениями и внедрение усовершенствований. Это предусматривает также связи с
заинтересованными лицами;
 контроль интерфейсов и границ. Хозяин процесса должен обеспечить плавность пе-
рехода от процесса к процессу, поскольку во многих случаях проблемы в сквозных процес-
сах возникают на стыках подпроцессов. Хозяин процесса должен добиться четкого понима-
ния границ между процессами и их строгого документального оформления;
 автоматизация процессов. Хозяин процесса обязан участвовать во всех действиях по
автоматизации, связанной с процессами. Нужно помнить, что многие приложения ИТ захва-
тывают несколько различных процессов;
 управление эффективностью процессов. Хозяин процессов должен обеспечить изме-
рение эффективности процессов и их вклада в реализацию целей и стратегии организации, а
также принятие мер на основе этих данных соответствующими сотрудниками. Другими сло-
вами, хозяин процесса добивается управления процессами, чтобы они достигали своих це-
лей;
 пропаганда процессов. Хозяин процессов должен пропагандировать правильное поль-
зование самим процессом, а также процессное мышление вообще.
Вызовы. На уровне 4 важно решить следующие проблемы:
 чтобы убедить руководство высокого ранга в своей необходимости, CPO должен до-
казать полезность выполняемых им действий, поскольку многие руководители считают CPO
просто еще одним уровнем в организации;
 CPO должен сохранять стратегическую направленность и не слишком погружаться в
повседневное руководство CBPE, поскольку это абсолютно другая роль, для которой годится
человек, обладающий специальными качествами;
 CPO должен быть способен вносить вклад на уровне правления, поскольку у всех
остальных исполнительных руководителей и подразделения больше, и людей больше, и
бюджеты богаче. Поэтому CPO должен обладать прозорливостью, чтобы превратить свой
вклад в осязаемые результаты, что обеспечит предоставление другими руководителями не-
обходимого финансирования, ресурсов и людей для реализации инициатив BPM. Найти та-
кого человека — уже проблема, потому что он должен видеть стратегическую перспективу и
владеть детальным пониманием операционных процессов, не опускаясь до мелочей.
Важно сказать пару слов предостережения. CPO особенно полезен в процессно-
ориентированной организации, достигшей зрелости в процессном развитии. Если организа-
ция еще движется к такому уровню зрелости, лучшим вариантом будет программа BPM по
усовершенствованию, которую поддерживает высший руководитель и старшее руководство,
а назначение CPO следует отложить до лучших времен.
Назначение CPO или образование CBPE в организации, которая недостаточно созрела
для их понимания или поддержки, серьезно скажется на ценности и пользе, которую они мо-
гут принести организации, и может повлечь трудности в оправдании высоких ожиданий,
связываемых с их ролью.
Принадлежность процессов. Правильное и ясное распределение ответственности и под-
чиненности в процессах — один из самых трудных вызовов в управлении бизнес-
процессами.
В отношении принадлежности хозяевам процессов у организации есть несколько воз-
можностей выбора:
 можно сделать функциональных менеджеров ответственными только за свою часть
процесса (участок сквозного процесса, т.е. подпроцесс);
 можно назначить функционального менеджера ответственным за весь сквозной про-
цесс;
 можно назначить ответственным за весь сквозной процесс менеджера, не имеющего
функциональной ответственности.
Каков бы ни был выбор, с ним сопряжены вызовы и риски:
1. функциональный заведующий подпроцессом. Риск, сопряженный с этим подходом, со-
стоит в том, что хозяева подпроцессов будут видеть только свой участок процесса (картина
комплекса-мешанины), и изменения в данном подпроцессе могут негативно сказаться на
других участках сквозного процесса, что опять же приведет к субоптимизации сквозных
процессов.
2. Функциональный заведующий сквозным процессом. Трудность этого подхода заклю-
чается в конфликте интересов «хозяина» сквозного процесса. Отвечая и за сквозной процесс,
и за его функциональные комплексы (подпроцесс), хозяевам процессов, возможно, придется
вносить изменения в пользу сквозного процесса, которые скажутся на рентабельности их
собственных функциональных комплексов и операционной эффективности. Такое управле-
ние процессами может потенциально привести либо к недостаточной прозрачности процес-
сов в целом, либо к использованию функциональными менеджерами собственной ответ-
ственности за сквозной процесс ради личных функциональных показателей.
1. Заведующий процессом без функциональной ответственности. Хотя данный подход
свободен от недостатков двух предыдущих, управление им может представлять серьезный
вызов, поскольку нужно заручиться согласием функциональных менеджеров. Для эффектив-
ной работы назначенный таким образом человек должен быть руководителем высокого ран-
га или весьма уважаемым в организации менеджером. Он должен владеть искусством убеж-
дать функциональных менеджеров иногда принимать точку зрения сквозного процесса. Та-
кое лицо можно назвать «распорядителем» процессов, поскольку у него нет обычных опера-
ционных обязанностей, но есть полномочия распоряжаться сквозным процессом. Вызов,
стоящий перед распорядителем сквозного процесса, состоит в том, чтобы справляться с по-
пытками субоптимизации со стороны функциональных менеджеров и преследовать цели
сквозного процесса. В подобных ситуациях бывает разумно подчинить заведующего сквоз-
ным процесса главному руководителю процессов CPO или главному операционному руко-
водителю СОО.
Если организация достигла чрезвычайно высокой степени зрелости BPM, ответствен-
ность за процессы может быть распределена линейно по сквозным процессам, а структура
функциональной мешанины организации устранена (или хотя бы минимизирована). В таком
случае важно, чтобы работники, выполняющие различные функции, имели возможность де-
литься своими знаниями и опытом в области процессов.

Часть IV Приложения: инструменты и методы

Одна из целей этой книги — обеспечить практическое руководство для менеджеров и прак-
тиков BPM. Чтобы помочь в разработке методических указаний, описанных в общей схеме, в
Приложениях ниже приведены типовые шаблоны, сверочные списки и дополнительная ин-
формация. Все это окажет практическую помощь группе проекта при реализации проектов
BPM.
Для каждого этапа общей схемы проекта BPM имеется отдельное Приложение, содержа-
щее, как минимум, сверочный список исходной информации и данных на выходе; в боль-
шинстве приложений имеется дополнительная информация. Разумеется, включить весь ин-
струментарий и методы в эту книгу невозможно, иначе она была бы на сотни страниц толще,
поэтому выбраны лишь инструменты и методы, которые увязаны с общей схемой и, по
нашему мнению, дают нечто ценное для практика BPM.
Многие инструменты, шаблоны и сверочные списки представлены с любезного разреше-
ния консультационной фирмы TouchPoint Business Process Management Consultancy (MPM
Group Pty Limited). Фирма постоянно работает над усовершенствованием этих инструментов
и шаблонов, так что если у читателя появятся предложения по улучшению или новые полез-
ные инструменты и шаблоны, можно направить их по электронной почте на
framework@touchpointbpm.com.au.
Приложение А
Этап разработки стратегии
Сверочный список: этап разработки стратегии
Сверочный список ниже дает общее описание возможных исходных данных, конкретных ре-
зультатов и шлюзов, препятствующих дальнейшим шагам на этом этапе.
Возможные исходные данные:
 имеющиеся формулировки:
o миссии;
o общего видения долгосрочных задач и целей;
o ценностей организации.
 корпоративные брошюры, сайты, годовой отчет и т.п. для формирования имиджа ор-
ганизации;
 программа ввода, дающая исходные данные для ключевых ценностей стратегии внед-
рения в организации;
 организационная схема, помогающая выявить основных внутренних заинтересован-
ных сторон;
 состав портфеля продуктов для определения основных продуктов;
 ключевые типы группы клиентов;
 модель бизнеса для определения основных внешних партнеров.
Конкретные результаты:
 документально оформленные версии (если не имеются в виде документов):
o общего видения задач и целей организации на длительный срок;
o миссии организации;
o задач;
o стратегического устремления;
o целей;
 контекст или модель бизнеса, что включает:
o клиентов (по типам и объемам);
o услуги продукты;
o поставщиков партнеров;
o ключевые выделяющие (дифференцирующие) факторы;
o ресурсы;
 ключевые выделяющие особенности организации;
 распространение результатов данного этапа.
Возможные шлюзы:
 осознание масштаба изменений;
 способность организации к переменам;
 воспринимаемость BPM организацией.
Самооценка стратегии
Цель
Использование этого средства подскажет, каким образом разные сотрудники организации
воспринимают различные аспекты бизнес-стратегии. Получить такое видение изнутри кри-
тически важно для моделирования процессов. Если нет консенсуса по выбору стратегии, не-
возможно достичь консенсуса по выбору наилучшего способа моделирования процессов.
Заполнение опросного листа
1. Опросный лист раздается всем участникам анкетирования.
2. Участники анкетирования заполняют опросные листы самостоятельно, исходя из сво-
его видения текущей ситуации.
3. В принципе, все начисляемые баллы должны быть распределены. Баллы не начисля-
ются, только если неприменим ни один вариант ответа.
4. Подсчет суммы баллов по всем пяти аспектам; суммы указываются в листе ответа.
5. Подсчет суммы по всем пяти аспектам и всем участникам анкетирования в итоговом
отчете.
6. Показ индивидуальных диаграмм и диаграмм по аспектам.
7. Обсуждение участниками результатов и следствий.
8. Принятие решения по изменениям и следующим действиям, которые нужно предпри-
нять.
Лист опроса
Приведенный ниже лист оформлен в виде электронной таблицы Excel, в которую участники
анкетирования вносят свои ответы. Диаграммы на рис. П.1 и П.2 создаются автоматически.
При раздаче опросного листа участникам анкетирования необходимо убедиться, что за-
головки столбцов вверху опросного листа скрыты (не видны), потому что они могут пред-
определить ответы на вопросы.

Опросный лист самооценки стратегии принадлежит Полу Ван дер Марку (Paul van der
Marck) и взят с сайта www.management.net по состоянию на 11 июля 2005 года.
Предположение ценности Совершенство Лидирующее Доверительные
функционирования положение про- отношения с
дукта клиентом
Распределите 20 баллов среди следующих трех утверждений:
1. Мы предлагаем нашим клиентам уникаль-
ное сочетание цены, линейки продуктов и простоты
использования. Итоговые затраты для клиента (де-
нежные средства, время и усилия) минимальны по
сравнению с приобретаемой ценностью (продукт и
сервис)
2. Мы предлагаем нашим клиентам уникаль-
ную ценность продукта и способны постоянно по-
вышать ценность предложения и соответствовать
ожиданиям клиентов или повышать их (наши ис-
следования, как и способность выполнять обеща-
ния, «первоклассны»)
3. Мы предлагаем нашим клиентам уникаль-
ное и ценное полное комплексное решение посред-
ством наших продуктов и услуг, наш сервис инди-
видуален, всегда благожелателен и продуктивен,
мы способны подстраивать наше решение под ин-
дивидуальные запросы клиентов
Итого
Процессы
Распределите 4 балла среди следующих трех утверждений:
1. Время прохождения сквозного процесса
для нашего клиента сокращено до абсолютного ми-
нимума
2. Исследования и разработки являются ос-
новным процессом для удовлетворения нашего кли-
ента
3. Мы постоянно сосредоточены на разработ-
ке полного комплексного индивидуального реше-
ния для каждого клиента
Распределите 4 балла среди следующих трех утверждений:
1. Наш сквозной процесс работы с клиентом
управляется централизованно
2. Исследования рынка играют важную роль в
наших разработках
3. Наши процессы постоянно адаптируются с
целью удовлетворения наших клиентов
Распределите 4 балла среди следующих трех утверждений:
1. Дальнейшее снижение затрат в наших про-
цессах невозможно
2. Быстрый цикл разработки встроен в наши
стандартные процессы
3. Основной показатель функционирования
наших процессов – удовлетворенность клиентов
Распределите 4 балла среди следующих трех утверждений:
1. Ошибки процессов сведены к теоретиче-
скому минимуму
2. Наша процессная модель – параллельная
разработка нескольких концепций
3. У нашего клиента всегда есть четкое пред-
ставление о том. что мы делаем
Распределите 4 балла среди следующих трех утверждений:
1. Оптимизация процессов в центре нашего
главного внимания
2. Наш маркетинговый процесс нацелен на
постоянное использование наших продуктов и
услуг
3. Управление взаимоотношениями является
нашим главным процессом
Итого
Структура организации
Распределите 4 балла среди следующих трех утверждений:
1. Наша деятельность предельно стандарти-
зирована
2. Направление исследований и разработок
является отдельным подразделением
3. Наша деятельность весьма вариативна и за-
висит от клиента
Распределите 4 балла среди следующих трех утверждений:
1. Наше планирование строго централизовано
и ведется по принципу «сверху-вниз»
2. Подразделение разработки продуктов
находится вверху организационной схемы
3. Для каждого клиента планирование осу-
ществляется «снизу-вверх»
Распределите 4 балла среди следующих трех утверждений:
1. Сфера ответственности и обязанностей
четко очерчена, работа всегда ведется согласно ру-
ководствам и методическим указаниям
2. Наши усилия в разработке нацелены глав-
ным образом на «инструменты разработки»
3. Нашу клиентскую информацию можно
быстро и легко извлечь и просмотреть
Распределите 4 балла среди следующих трех утверждений:
1. Наша биллинговая система полностью
электронная
2. Наши системы легко адаптируемы, что
позволяет быстро настраиваться на разработку про-
дуктов
3. Наши конечные потребители имеют пря-
мой доступ к нашим системам
Распределите 4 балла среди следующих трех утверждений:
1. Наши поставщики непосредственно связа-
ны с нашими системами
2. Наши системы очень часто «вынуждают»
нас вводить новые продукты / концепции
3. Наши системы сосредоточены на удержа-
нии клиентов и повторяемости сделок
Распределите 4 балла среди следующих трех утверждений:
1. Наше подразделение обслуживания клиен-
тов поддерживается новейшей технологией, чтобы
иметь возможность быстро и эффективно отвечать
на вопросы
2. Сотрудники по обслуживанию клиентов
постоянно обучаются новым продуктам, поскольку
продукты часто меняются
3. Мы отслеживаем в системах клиентов, ко-
торые ушли от нас
Итого
Культура
Распределите 4 балла среди следующих трех утверждений:
1. Наши сотрудники высоко мотивированы,
чтобы не совершать ошибок
2. Наши сотрудники высоко мотивированы на
постоянную разработку новых идей
3. Наши сотрудники высоко мотивированы на
удовлетворение клиентов
Распределите 4 балла среди следующих трех утверждений:
1. Наша система поощрений вознаграждает
эффективность
2. Наша система поощрений вознаграждает
творческий подход
3. Наша система поощрений вознаграждает за
удовлетворенность клиента
Распределите 4 балла среди следующих трех утверждений:
1. Наша система подбора персонала нацелена
на поиск эффективно работающих сотрудников
2. Наша система подбора персонала нацелена
на поиск инновационно-мыслящих и творческих
сотрудников
 3. Наша система подбора персонала нацелена
на поиск сотрудников, ориентированных на клиента

1. Все нацелены на снижение затрат

2. Все нацелены на постоянное совершен-
ствование продукта
3. Все нацелены на удовлетворенность клиен-
та
Распределите 4 балла среди следующих трех утверждений:
1. Наши руководители – образец эффективно-
сти
2. Наши руководители – образец творчества
3. Наши руководители – образец ориентации
на клиента
Итого
Всего баллов = 100

Лист ответов на анкетирование

Аспект Критерии Балл
Совершенство функционирования (1 столбец)
1. Предложение ценности Лучшая ценность за уплаченную стоимость
2. Процесс Сквозная оптимизация
3. Структура (организация) Строго контролируемое и централизованное планиро-
вание
4. Система управления Стандартизированы и нацелены на быстрое прохож-
дение транзакций
5. Культура Вознаграждается эффективность
Лидирующее положение продукта (2 столбец)
1. Предложение ценности Лучший продукт, независимо от цены
2. Процесс Фокус на исследования и разработки и использование
рынка
3. Структура (организация) Специализация и повторное использование ресурсов
4. Система управления Измерение успешности продуктов со способностью к
эксперименту
5. Культура Вознаграждается предвидение и инновации
Доверительные отношения с клиентом (3 столбец)
1. Предложение ценности Лучшее полное комплексное решение
2. Процесс Ориентирован на результат: управление взаимоотно-
шениями с клиентами
3. Структура (организация) Санкционирование принятия решений максимально
приближено к клиенту
4. Система управления Нацелены на избранных клиентов, окружение клиен-
тов заботой
5. Культура Стимулирует настройку на клиента и взаимоотноше-
ния с ним
Приложение B
Этап архитектуры процессов
Сверочный список: этап архитектуры процессов
Сверочный список ниже дает общее описание возможных исходных данных, конкретных ре-
зультатов на выходе и шлюзов, препятствующих дальнейшим шагам на этом этапе.
Возможные исходные данные
С этапа стратегии организации:
 документально оформленные версии:
o общего видения задач и целей организации на длительный срок;
o миссии организации;
o задач;
o стратегических направлений;
o целей (целевых показателей);
 контекст или модель бизнеса, что включает:
o клиентов (по типам и объемам);
o услуги/продукты;
o поставщиков/партнеров;
o ключевые выделяющие (дифференцирующие) факторы;
o ресурсы;
 ключевые выделяющие особенности организации.
Другая исходная информация на входе:
 архитектура предприятия для определения, как в нее укладывается архитектура про-
цессов;
 модель продуктов и услуг для использования как части моделей архитектуры процес-
сов;
 стратегия в сфере персонала для учета в соответствующих рассматриваемых вопросах
организации;
 архитектура информации и технологий для определения того, каким образом она
поддерживает архитектуру процессов;
 шаблоны архитектуры, которых следует придерживаться при завершении формиро-
вания архитектуры процессов;
 типовые образцы моделей на основе отраслевых стандартов.
Конкретные результаты:
 документально оформленная и согласованная заинтересованными сторонами архи-
тектура процессов;
 архитектура запуска процессов;
 видение процессов организации;
 перечень сквозных процессов;
 схема управления реализацией выгод (с этапа реализации ценности);
 распространение итогов.
Возможные шлюзы:
 осознание масштаба изменений;
 способность организации к переменам;
 воспринимаемость BPM организацией.
Образец типовой архитектуры
Обобщенные целевые показатели:
 в следующие три года обеспечить рост выручки от реализации на 200%;
 обеспечить рост прибыли на 150% в следующие три года.
Общие принципы:
 наши корпоративные ценности:
o лучшая ценность за уплаченную цену;
o честность: мы обещаем, что сделаем, и делаем то, что обещали;
o вознаграждение: результативность и инновации вознаграждаются везде в ор-
ганизации;
 мы придерживаемся стратегии совершенства функционирования с агрессивно низки-
ми ценами и достигаем совершенства за счет:
 экономии на масштабах (предлагаем услуги, тольк
 o о можем достичь порогового объема);
o строгой и экономной организации, процессов и систем приложений;
 мы открыто заявляем целевые показатели и стратегический выбор;
 мы придерживаемся принципа расширения полномочий персонала; сотрудников по-
ощряют за принятие ответственности и предприимчивость в рамках данной общей
схемы;
 мы стремимся стать выдающейся национальной организацией; мы нацелены на все
население; у нас (пока) нет международных устремлений;
 мы выбираем лучшие практические методы и не изобретаем собственные методики и
инструменты. Если нам не удается соответствовать лучшим практическим образцам
в конкретной сфере собственными силами, мы передаем такую деятельность на под-
ряд (аутсорсинг);
 мы отдаем себе отчет, что работаем на динамично развивающемся рынке и стремим-
ся, чтобы организация и все ее элементы оставались маневренными и гибкими.
Направляющие соображения по продуктам:
 у нас ограниченный состав продуктов и компонент;
 клиенты могут получить наиболее приемлемый вариант решения, исходя из наших
компонентов продуктов;
 скидки зависят исключительно от итоговой оплачиваемой суммы и применяются ко
всем заказчикам;
 мы не изобретаем продукты сами; берем на вооружение существующие перспектив-
ные предложения;
 мы намерены сотрудничать с другими организациями, предлагающими достойную
ценность за оплачиваемую цену, как в нашей сфере (например, продажи по телефо-
ну), так и вне ее (например, супермаркеты).
Направляющие соображения по организации:
 у нас единая организация;
 мы поощряем расширение полномочий сотрудников и даем рекомендации, как этого
добиваться;
 мы призываем сотрудников использовать свой потенциал и отдаем предпочтение
кандидатам на вакантные должности из числа сотрудников;
 наша организационная структура гибкая и экономная;
 мы следуем принципу обучающейся организации и на всех уровнях задаем соответ-
ствующие целевые показатели;
 у каждого сотрудника имеются премиальные в зависимости от его показателей произ-
водительности, а также подразделения в целом.
Направляющие соображения по процессам:
 мы рассматриваем процессы под углом зрения полноты из конца в конец;
 у каждого процесса есть хозяин;
 для каждой бизнес-функции есть только один процесс, выполняемый по умолчанию;
все исключения требуют утверждения советом директоров;
 архитектура процессов требует включения выбора соответствующих типовых моде-
лей;
 не будет отдельных адаптируемых процессов для отдельных клиентов; если поступа-
ет заказ, он оценивается, исходя из единых принципов;
 мы стремимся к сокращению операций передачи процессов от одного исполнителя к
другому;
 если возможно, работа автоматизируется, но при обеспечении гибкости;
 у всех процессов имеются показатели производительности; эти показатели открыты
для каждого.
Направляющие соображения по информации:
 для каждой бизнес-функции (например, обслуживание клиентов, биллинг, финансы)
имеется только одна система; исключения требуют одобрения совета директоров;
 следующие приложения являются стандартом:
o А/В/С;
 следующие приложения доступны после утверждения руководством:
o Z/Y/X;
  все остальные приложения требуют утверждения советом директором;
 вся разработка программного обеспечения передается на аутсорсинг;
 все данные вводятся только однократно (если аналогичные данные размещены в не-
скольких местах, они должны автоматически синхронизироваться).
Направляющие соображения по технологиям:
 в качестве операционной платформы используется ×;
 используется серверная конфигурация простых клиентов.
Помимо вышеперечисленного частью процессной архитектуры будут модели. Модели
процессов, которые должны быть сформированы на этапе архитектура процессов, включают:
 картину процессов организации;
 перечень сквозных процессов.
К архитектуре процессов будут добавляться и модели, создаваемые на дальнейших эта-
пах, в частности:
 модели сквозных процессов;
 подробные модели процессов (различных уровней).
Модели для других сфер включают все целесообразные модели продуктов и услуг, соот-
ветствующие организационные схемы, информационные и технологические модели.
Приложение C
Этап стартовой площадки
Сверочный список: этап стартовой площадки
Сверочный список ниже дает общее описание возможных исходных данных, конкретных ре-
зультатов и шлюзов, препятствующих дальнейшим шагам этого этапа.
Возможные исходные данные
С этапа стратегии организации:
 документально оформленные версии: общего видения задач и целей организации на
длительный срок, миссии организации, задач, стратегических направлений, целей
(целевых показателей) и стратегии реализации;
 контекст или модель бизнеса, что включает клиентов (по типам и объемам), услу-
ги/продукты, поставщиков/партнеров, ключевые выделяющие (дифференцирующие)
факторы, ресурсы;
 ключевые выделяющие особенности организации.
С этапа архитектуры процессов:
 документированная и согласованная архитектура процессов (включает картину про-
цессов организации);
 архитектура запуска процессов (включая соответствующие сквозные процессы);
 схема управления получением выгод.
Другая исходная информация на входе:
 шаблон обоснования проекта;
 общие метрики с целью выявить основные процессы и явные «узкие места»;
 перечень увязанных проектов с целью определить синергию и взаимное пересечение.
Конкретные результаты:
 заинтересованные стороны, определенные в проекте, участвующие в нем или связан-
ные с ним;
 привлечение заинтересованных сторон, их обязательства, а также документированные
и согласованные ожидания от проекта;
 матрица выбора процессов и начальные метрики;
 перечень согласованных задач проекта;
 матрица стоимостей проекта;
 процессы в порядке приоритета для этапа осознания;
 управление проектом:
o организована группа проекта;
o создано положение о проекте;
o разработан документ об объеме проекта;
o первоначальный проект плана проекта (на этапе осознания план будет дорабо-
тан в подробностях);
o определение и документирование начальной стратегии распространения ин-
формации о проекте;
o начальный анализ рисков;
 исходное бизнес-обоснование;
 потенциальных выгод проекта и их реализации (с этапа реализации ценностей);
 распространение результатов.
Возможные шлюзы:
 анализ состава заинтересованных сторон;
 осознание масштаба изменений;
 способность организации к переменам;
 принятие BPM организацией;
 техническое обследование;
 наличие участников для работы на практических семинарах.
Структура и роли участников группы проекта

В данном Приложении подробно описана структура группы проекта «на все случаи жиз-
ни». Как правило, такая типовая структура модифицируется под требования конкретной ор-
ганизации. Тем не менее, по нашему опыту, эта структура особенно эффективна и работо-
способна, так что излишняя ее модификация может привести к снижению эффективности
проекта. Разумеется, размах проекта BPM — важный фактор при рассмотрении структуры
группы проекта.
Спонсор проекта. Роль спонсора проекта — обычная для бизнес-проекта. Часто в роли спон-
сора выступает ведущий бизнес-менеджер. Спонсор проекта должен быть его активным сто-
ронником и защитником, выполняя следующие обязанности и неся ответственность за:
 определение и утверждение задач, целевых показателей, ограничений и критериев
успеха проекта;
 утверждение объема проекта;
 утверждение документа, описывающего проект;
 утверждение плана проекта;
 санкционирование или получение санкции на ресурсы и расходы по проекту;
 утверждение или отказ любых требований о внесении изменений, которые выходят за
пределы ранее утвержденного объема проекта;
 утверждение бюджета проекта;
 утверждение завершения проекта, когда выполнен объем проекта.
Директор проекта. В сферу ответственности директора проекта входит вся деятельность,
связанная с проектом. Менеджер (менеджеры) проекта и руководители рабочих направлений
проекта непосредственно подчиняются директору проекта.
Эта роль обеспечивает реализацию проекта «без сучка и задоринки» и соответствие ожи-
даниям заинтересованных сторон. Директор проекта также обязан поддерживать взаимоот-
ношения со всеми заинтересованными сторонами и обеспечить правильное применение опи-
санной общей схемы в условиях конкретной организации. Среди других обязанностей, свя-
занных с проектом:
 инфраструктура и архитектура;
  координации управления техническими и другими средствами;
 управление качеством и удовлетворительное вовлечение персонала в это;
 человеческие ресурсы (как описано в различных главах этой книги);
 управление изменениями персонала и вовлечение в этот процесс сотрудников — дан-
ную сферу особенно нельзя недооценивать, поскольку это, возможно, самая объем-
ная и одна из самых важных составляющих любого проекта BPM;
 поддержка менеджеров проекта и персонала, особенно при получении согласований
или обеспечении действий других частей организации;
 обеспечение группы проекта необходимыми ресурсами и средствами.
Хотя выполнение и координация всех вышеперечисленных функций входит в сферу от-
ветственности менеджеров проекта, директор проекта должен иметь полную картину страте-
гического выполнения и выстраивания проекта.
Менеджер (менеджеры) проекта. Сфера ответственности менеджера (менеджеров) проекта
включает выполнение и координацию проекта, в т.ч.:
 повседневное управление своей частью проекта и ее выполнение;
 разработку политики и планов обеспечения общности процессов и систем везде, где
это возможно;
 обеспечение учета и отработки всех вопросов управления изменениями персонала,
человеческих ресурсов и обучения;
 управление всей деятельностью, связанной с проектом, по обеспечению удовлетворе-
ния требований заинтересованных сторон в запланированные сроки, в рамках бюд-
жета и с соответствующим качеством;
 подготовку и отслеживание своей части бюджета;
 получение обязательств всех заинтересованных сторон;
 координацию и получение согласований планов проекта;
 организацию и использование контролирующих механизмов проекта, чтобы обеспе-
чить управляемость согласованных графиков и бюджетов;
 отчет о ходе выполнения проекта всем заинтересованным сторонам в согласованные
сроки;
 непрерывную связь с управлением предприятием (бизнесом) и ИТ;
 определение и установление каналов связи с увязываемыми проектами, управление
рисками, которые может породить взаимозависимость;
 определение, управление и при необходимости передачу на более высокий уровень
должностной ответственности потенциальных или имеющихся проблем, которые в
случае игнорирования могут отрицательно сказаться на проекте;
 мониторинг рисков, связанных с проектом, и рекомендации директору и спонсору
проекта.
Подгруппы процессов, часто называемые направлениями работы, включают разных специа-
листов.
1. Глава подгруппы.
2. Руководитель пользователей.
3. Представитель пользователей.
4. Эксперт по процессам.
Глава подгруппы - обычная роль руководителя подгруппы проекта. Возглавляет свою под-
группу (направление работы) и обеспечивает организацию практических семинаров, разра-
ботку плана проекта (совместно с менеджером проекта), соблюдение графика процесса, ис-
полнение бюджета и т.п. Эта роль также предусматривает:
 управление назначенными заданиями (либо выполнение их самостоятельно, либо
назначение членов подгруппы);
 регулярное рассмотрение работы подгруппы;
 составление регулярных отчетов о работе подгруппы для включения в общий отчет
по проекту;
 участие в регулярных совещаниях по рассмотрению состояния дел проекта;
 помощь в решении проблем проекта или бизнеса;
 обеспечение регистрации всех проблем и их быстрого решения или передачи в ком-
петенцию менеджера проекта и группы проекта;
  руководство разработкой программы приемных испытаний пользователей и схем ис-
пытаний, а также их успешным выполнением;
 получение согласований программы приемных испытаний пользователями в своей
зоне ответственности;
 выполнение плана реализации в своей зоне ответственности.
Руководитель пользователей — бизнес-ресурс. Его назначает бизнес-руководство, и у него
есть полномочия принимать решения от имени предприятия. Эта роль предусматривает:
 подбор членов подгрупп пользователей (в подразделениях и по подразделениям);
 обеспечение технического качества и решений по проектированию процессов;
 разрешение возможных конфликтов;
 представительство группы пользователей в группе по принятию решений проекта;
 участие в совещаниях всех руководителей пользователей проектов;
 работа с другими руководителями пользователей в целях правильного взаимодей-
ствия и передачи дел, обменов и т.п., чтобы не было нестыковок.
Представитель пользователей — это технический специалист или эксперт в предметной
области со стороны бизнеса. Их подбирает руководитель пользователей. В сферу их ответ-
ственности входит:
 участие в практических семинарах и собеседованиях;
 выработка конкретных подходов подгруппы к деятельности в рамках проекта;
 разработка различных подходов на этапе инноваций;
 учет вопросов качества, соответствия различным нормативным и техническим требо-
ваниям;
 нахождение согласия с другими подгруппами по взаимодействию в рамках проекта и
обмена материалами и т.п., чтобы избежать нестыковок;
 участие в планировании программы пользовательских приемных испытаний;
 участие в составлении планов и схем пользовательских приемных испытаний;
 участие в выполнении пользовательских приемных испытаний;
 участие в планировании и внедрения и реализации.
Эксперт по процессам - специалист Центра совершенствования бизнес-процессов (CBPE), со
специальными знаниями:
 проектирования и перепланирования процессов;
 инструментов проектирования процессов, используемых в проекте;
 расчета расходов по типу работ;
 имитационного моделирования процессов;
 состыковки процессов.
Типовой шаблон бизнес-обоснования
Далее обсуждается назначение и предлагается примерное содержание бизнес-обоснования
проекта.
Цель бизнес-обоснования. Бизнес-обоснование является важным подспорьем в управле-
нии проектом BPM и выполняет три главные функции:
1. при запуске проекта обоснование дает информацию, позволяющую принять решение
об утверждении предлагаемого проекта и его финансировании. Другими словами, оно позво-
ляет определить, оправдывают ли предполагаемые выгоды требуемые вложения в проект с
учетом рисков и альтернатив. Польза и выгоды, получаемые в результате проекта, должны
быть четко определены.
2. В ходе реализации проекта обоснование задает общую канву, позволяющую удержи-
вать проект «на правильных рельсах». Это имеет важнейшее значение — в течение срока ре-
ализации проекта предприятие эволюционирует, поэтому спонсор и менеджер проекта
должны постоянно проверять, что проект по-прежнему вносит вклад в стратегию организа-
ции и желаемые выгоды. Другими словами, спонсор и менеджер проекта должны постоянно
«контролировать экономическую обоснованность и целесообразность проекта».
3. После завершения проекта его обоснование даст бизнес-группе и группе проекта воз-
можность оценить, дал ли проект ожидаемые результаты (пользу, выгоды) и вклад в дости-
жение конкретных целевых показателей в рамках выделенного бюджета и в установленный
срок. Такая оценка позволяет извлечь важнейшие уроки, которые очень пригодятся в после-
дующих проектах BPM.
Содержание обоснования проекта
1. Краткое изложение. Предназначено дать краткий обзор экономического обоснования.
Должно быть очень кратким и строго по делу.
1.1. Описание проекта. Держатель проекта.
1.2. Требования бизнеса.
1.3. Стратегический вклад.
1.4. Финансовая сводка (включая выгоды и затраты).
1.5. Решающие факторы успеха проекта.
1.6. Анализ рисков.
1.7. Рекомендуемые последующие действия.
2. Предпосылки
2.1. Анализ проблемы.
3. Целевые показатели
3.1. Цели бизнеса.
3.2. Цели проекта.
3.3. Решающие факторы успеха.
4. Объем проекта
4.1. Конкретный выход и результаты.
4.2. Включения и исключения.
4.3. Зависимости.
4.4. Анализ сторон, заинтересованных в проекте.
4.5. Предположения и допущения.
4.6. Ограничения.
4.7. Связанные документы.
4.8. Соответствие требованиям архитектуры.
5. Проектный подход
5.1. Изученные варианты:
5.1.1. Вариант 1
5.1.1.1. Ожидаемые результаты
5.1.1.2. Выгоды
5.1.1.3. Расходы по проекту
5.1.1.4. Окупаемость вложений в проект и проч.
5.2. Предпочтительный подход
6. План-график проекта
6.1. Длительность проекта
6.2. Укрупненный план реализации
 7. Ресурсы
7.1. Внутренние заинтересованные стороны проекта — взаимодействие с другими под-
разделениями
7.2. Требования к ресурсу персонала
7.3. Другие ресурсы проекта
8. Предварительный анализ рисков
Типовая форма отчета. Далее приведен перечень вопросов, которые можно включить
в отчет о проекте. Отчет охватывает этапы стартовой площадки, понимания и инноваций.
Мы считаем, что отчет следует заполнять по мере завершения каждого этапа. Разделы 2 и 3
заполняются по окончании этапа стартовой площадки, раздел 4 — по окончании этапа пони-
мания, а остальное — по окончании этапа инноваций.
Есть некоторые пересечения между информацией в отчете и экономическим обоснова-
нием. Отчет предназначен для руководства организации, и для заполнения нескольких его
разделов можно воспользоваться экономическим обоснованием, которое предназначено для
спонсора проекта и руководящего комитета в части процедуры утверждения проекта. Абсо-
лютно необходимо взаимно согласовать два этих документа.
Данный отчет часто используется в конце этапа инноваций, чтобы обосновать целесооб-
разность продолжение проекта на этапы персонала, разработки и внедрения.
Типовая структура отчета приведена ниже.
1. Краткое изложение
1.1. Предпосылки.
1.2. Сфера охвата.
1.3. Подход.
1.4. Основные результаты.
1.5. Рекомендации.
2. Проект
2.1. Предпосылки.
2.2. Сфера охвата.
2.3. Сверочный список для успеха проекта.
2.4. Этапы и составные части этапов.
2.5. Конкретные результаты.
2.6. Заинтересованные стороны.
3. Этап стартовой площадки
3.1. Предварительный анализ процессов.
3.2. Результаты анализа.
4. Этап понимания
4.1. Цель этапа понимания.
4.2. Проблемы процессов.
4.3. Результаты анализа.
5. Этап инноваций
5.1. Цель.
5.2. Подход.
5.3. Результаты анализа.
6. Рекомендации
6.1. Сценарий 1 — быстрый выигрыш.
6.2. Сценарий 2 (может быть один или несколько сценариев, выбранных
предприятием).
6.3. Подход к реализации.
6.4. Рекомендуемая структура проекта.
6.5. Управление изменениями.
6.6. Анализ рисков.
6.7. Связанные проекты.
7. Выгоды и преимущества
8. Кто вносит вклад
9. Приложение А — Метрики этапа понимания
10. Приложение B — Вопросы взаимодействия с внешними заинтересованными сторо-
нами
 11. Приложение С — Легенда карты процессов
12. Приложение D — Действующие процессные потоки
12.1. Перечень сквозных процессов.
12.2. Матрица выбора процессов.
12.3. Модели отдельных процессов.
13. Приложение Е — Перестроенные процессные потоки
13.1. Матрица инноваций процессов.
13.2. Сценарий 1 — Таблица моделей и имен файлов.
13.3. Анализ отдельных процессов.
13.4. Процесс 1.
13.5. Сценарий 2 — Таблица моделей и имен файлов.
14. Приложение G — Оценка метрик перестроенных процессов
15. Приложение Н — Анализ рисков
16. Приложение I — Матрица анализа требуемой квалификации

План-график проекта дает описание возможного списка заданий и приблизительное время

их выполнения. Менеджер проекта модифицирует этот план-график согласно конкретному
проекту.
Этап 1. Стартовая площадка (около двух недель)
Цель. Этап стартовой площадки формирует основу для выбора, определения объема, органи-
зации и запуска проектов BPM в подходе операционная инициатива. Хотя движимые страте-
гией проекты инициируются на этапе стратегии организации, все же необходимо оценить
усилия проекта на начальной стадии. Целью данного шага является получение понимания
усилий, вкладываемых в эту работу.
Этап 2. Понимание
Цель — получить достаточное понимание действующих бизнес-процессов, чтобы можно
было начинать этап стартовой площадки. Шаги этапа описаны в главе 16.
На этом этапе закладывается фундамент этапа инноваций. Анализируется и оценивается
текущая ситуация с ее требованиями и ограничениями. Возможно определение и реализация
быстрых выигрышей.
Шаги
Этап понимания главным образом осуществляется серией совещаний. Количество и продол-
жительность их зависит от объема проекта и понимания, сформированного на этапе старто-
вой площадки.
Грубая оценка предполагает планирование на одну неделю (состоит из четырех полуд-
невных совещаний) при наличии четырех-шести процессов, документально оформленных с
метриками и раскладкой по времени.
Шаг работы Продолжительность, дней

Сверка объема 0,25

Совещания: Зависит от количества про-

 сбор порядка протекания процессов; цессов в проекте
 сбор метрик (время, число работников, объемы);
 сбор данных по затратам;
документальные результаты

Анализ метрик процессов Зависит от количества про-

цессов в проекте

Анализ корневых проблем Зависит от количества про-

цессов в проекте

Матрица способностей персонала 1

Определение потребностей в знаниях и информации 1

Определение приоритетов для этапа инноваций 1

Определение быстрых выигрышей (явных, выявленных на 1

практических совещаниях)
 обсуждение с бизнесом;
 выбор быстрых выигрышей для реализации;
приоритеты

Варианты для внедрения (не являются частью данного 2

проекта):
 передать для внедрения бизнесу;
 обозначить отдельные проекты (с отдельными
группами);
 поставить срок действующей группе проекта на ре-
ализацию быстрых выигрышей, а затем вернуться к
проекту

Составить отчет и представить его руководству, включая: 4–6

 перечень сквозных процессов;
 документацию действующих процессов с метрика-
ми;
 матрицу способностей персонала;
 потребности в знаниях и информации;
 быстрые выигрыши
Разработать и представить руководству презентацию этапа 2

План проекта этапа инноваций, включая: 2

 длительность
 затраты
 структуру группы проекта (изменения и оценки
всех требуемых ресурсов)
Этап 3. Инновации (12~20 недель)
Цель
Цель этого этапа — сделать процессы в объеме проекта BPM максимально эффективными и
продуктивными, чтобы отвечать текущим и/или будущим ожиданиям заинтересованных
сторон. Этот этап также предоставляет отличную возможность дальнейшего количественно-
го определения выгод, указанных в бизнес-обосновании.
Этап инноваций заключается в разработке новых решений для бизнеса. Длительность и
объем работ этапа сильно зависят от целей и объема проекта (например, входят ли в объем
проекта системные изменения, сроки — кратко-, средне- или долгосрочный проект — долж-
ны ли произойти кардинальные изменения или «ползучие» улучшения).
Шаг работы Длительность, дней

Практическое совещание начала с руководством: 1

 задачи процессов;
 определение общего подхода (автоматизация,
без автоматизации и т.п.)

Фокус-группы внешних заинтересованных сторон 1

Начальное практическое совещание инноваций 1

Прогноз метрик будущих процессов 5–8

Имитационное моделирование в предположении: В зависимости от количества

 данные о метриках получены как на шагах процессов — ориентировочно 1–
метрик, так и из дополнительной информации, 3 на каждый процесс
накопленной на данном шаге;
 формирование моделей процессов с учетом
имитационного моделирования;
 приоритеты

Обновление матрицы способностей персонала с уче- 1

том новых квалификационных навыков, необходимых
в новых процессах

Планирование штата (персонала) 5–10

Обсуждение предложенных решений на практических Зависит от количества процессов

совещаний — см. замечания к началу данно-
го этапа

Доказательство осуществимости предложенных ре- 3

шений:
 соответствие законодательству и нормативным
актам;
 аудит

Анализ разрывов процессов 3–5

Шаг работы Длительность, дней

Определение и обновление бизнес-обоснования 5–8

Завершить отчет и презентацию для руководства, что

может включать:
 перечень согласованных задач процессов;
 документальное оформление перестраиваемых
процессов;
 основные выводы и анализ точек соприкосно-
вения процессов;
 согласованный сверочный список критериев
успеха;
 спецификации бизнес-требований, если целе-
сообразно;
 перечень рекомендаций (включая новые быст-
рые выигрыши);
 предварительный анализ рисков;
 сводка выгод/расходов;
 предлагаемые следующие шаги;
 окончательный перечень рекомендаций

Получение разрешения продолжить проект Зависит от организации

Составление документа спецификаций бизнес- Зависит от количества процессов

требований и требуемой детализации

Разработка плана общения/связей 3

Реализация плана общения/обмена информацией В течение всего цикла существо-

вания проекта

Управление проектом: В зависимости от объема и раз-

 длительность; мера проекта
 затраты;
 структура группы проекта (все требуемые ре-
сурсы)
Общее управление проектом
Нужно спланировать управление проектом таким образом, чтобы выделить достаточно вре-
мени и достаточно ресурсов бюджета. Планирование включает:
 управление рисками;
 управление изменениями в проекте;
 план общения/обмена информацией;
 статус проекта (отчет для спонсора проекта);
 совещания подгрупп проекта.
Время, выделяемое для этой работы, зависит от масштаба проекта и группы проекта.
Также очень важно предусмотреть в плане непредвиденные ситуации, чтобы уложиться в
сроки и в рамки бюджета.
Приложение D
Этап понимания. Сверочный список: этап понимания
Данный перечень дает общее представление о возможных входных данных, конкретных ре-
зультатах и шлюзах данного этапа.
Возможные исходные данные на входе этапа
С этапа архитектуры процессов:
 документально оформленная и согласованная архитектура процессов (включая карти-
ну процессов организации);
 архитектура запуска процессов (соответствующие сквозные процессы);
 схема управления выгодами.
С этапа стартовой площадки:
 заинтересованные стороны и лица, определенные в проекте, участвующие в нем или
связанные с ним;
 вовлечение заинтересованных сторон, степень их убежденности и документально
оформленные и согласованные ожидания;
 матрица выбора процессов и исходные метрики;
 перечень согласованных задач процессов;
 матрица ценности процессов;
 ранжирование процессов для этапа понимания;
 управление проектом:
o сформирована группа проекта;
o положение/устав проекта;
o объем проекта;
o начальный проект плана (план этапа понимания должен был составлен по-
дробно);
o формулировка и документальное оформление начальной стратегии общения;
o начальный анализ рисков;
o потенциальные выгоды проекта и план реализации;
o начальное бизнес-обоснование.
Конкретные результаты:
 модели действующих процессов;
 точка отсчета для сравнения метрик;
 быстрые выигрыши в порядке приоритета;
 матрица способностей персонала;
 потребности в информации и знаниях;
 перечень приоритетов для этапа инноваций;
 план проекта (подробный) для этапа инноваций;
 точки отсчета и сравнительные измерения (с этапа реализации ценности);
 отчет руководству;
 презентация для руководства;
 начальный план общения/обмена информацией.
Возможные шлюзы:
 невозможно получить удовлетворительные отсчетные метрики;
 нет специалистов по конкретным предметам.
Обзор уровней моделей процессов
Далее рассматривается пять или шесть уровней моделей процессов с указанием основных
достоинств каждого из них.
Уровень 0. Схема организационных взаимосвязей
Схема организационных взаимосвязей (впервые приведенная на рис. 14.9) показывает схему
взаимодействия организации со своими партнерами: клиентами, поставщиками и третьими
сторонами. В этой среде бизнесу можно рассматривать свои процессы. На рис. П.4 дан при-
мер процессов, встречающихся у провайдера связи, под другим углом зрения, отличным от
рис. 14.9.
Уровень 1. Картина процессов организации
Картина процессов организации дает самый общий вид организации под процессным углом
зрения. На рис. П.5 приведен пример страховой компании. Процессы обычно изображаются
или группируются по трем категориям:
1. Стратегические процессы играют стратегическую роль и обеспечивают выполнение и
постоянство достижения установленных показателей нижележащими процессами.
2. Опорные процессы представляют ядро, т.е. основную бизнес-деятельность организа-
ции.
3. Вспомогательные процессы (обеспечения), которые не являются опорными, но под-
держивают опорные процессы организации.
Преимущества картины процессов организации таковы:
 самый общий вид организации — все другие процессы привязываются к этой картине
процессов;
 отличный способ вовлечь руководителей высокого ранга в деятельность по модели-
рованию процессов; процессный взгляд на организацию;
 подобная процессно-ориентированная схема может поддерживать процессное мыш-
ление в организации; если она применяется последовательно, то может заменить ор-
ганизационно-структурную схему как единственная структурная схема внутри орга-
низации.
Уровень 2. Перечень сквозных процессов
Для каждой группы процессов, выделенной на картине процессов организации, должен быть
сформирован перечень сквозных процессов (см. рис. П.5).
Достоинства такого перечня таковы:
 дает связь между картиной процессов организации и отдельным сквозным процессом;
 обеспечивает концентрацию организации на сквозных процессах вместо функцио-
нальной мешанины.
Уровень 3. Модель сквозных процессов
Модель сквозного процесса описывает все основные операций (деятельности), которые
должны в нем выполняться. Такой процесс обычно проходит через различные функциональ-
ные участки организации, включая любой выбор общего характера, например утверждение
или отказ в удовлетворении требования возмещения ущерба (рис. П.6).

Преимущества модели сквозного процесса:

 дает простую картину основных типов деятельности
 формирует среду для подготовки детальных моделей процессов.
Матрица выбора процессов (уровни 2 и/или 3) — это способ показать связь перечня сквоз-
ных процессов (или основных типов деятельности) с выделенными сценариями. Например,
на рис. П.7:
 основной процесс A индивидуален для продукта 1 на рынке A (процесс 1);
 основной процесс B аналогичен для продукта 1 и продукта 2 на рынке А (процесс 5);
 основной процесс C не применим для продукта 1 на рынке C (нет процесса).

Достоинства матрицы выбора процессов:

 на одной-двух страницах дает картину основных сквозных процессов или типов дей-
ствий и их подобия/различий;
 позволяет установить, какие процессы требуют дальнейшего изучения, и помогает
определить объем проекта.
Уровень 4. Подробные модели процессов
Это первый уровень моделирования отдельных процессов. Здесь также определяются долж-
ности/структурные подразделения, документы, системы и внешние агенты. На этом уровне
можно предусматривать различные вариации (например, продажи по телефону, электронной
почте/факсу или лично) и больше условий (например, направлять заказ только после подпи-
сания контракта и получения оплаты).
В некоторых случаях отдельные действия определяются в более подробной модели. На
рис. П.8 приведена типовая модель процесса.
Основные достоинства подробных моделей процессов:
 четко документально оформляют протекание процесса;
 допускают простую интеграцию с основными процессами на более высоких уровнях
и с другими моделями процессов.
Уровень 5. Процедуры
Этот уровень пошагово описывает каждое отдельное задание. Следует помнить, что важно
развивать модели процессов, пока эти модели имеют смысл. Иногда уровень процедур
наиболее эффективно решается составлением текстового документа.
Основные достоинства процедур:
 дают четкое пошаговое описание деятельности;
 являются хорошим руководством для обучения новых сотрудников в процессе рабо-
ты.
 Дорожки (уровни 3 и/или 4)
 Дорожки могут оказаться полезными при сопоставлении процессов и определении
лица или подразделения, отвечающего за определенные задания. Здесь для каждого
лица или структурного подразделения имеется своя колонка, где указываются все вы-
полняемые ими процессы (типовая модель дорожек приведена на рис. П.9).

Некоторые инструменты моделирования и управления процессами дают возможность

переходить от блок-схем процессов к модели дорожек, поскольку это всего лишь иное пред-
ставление протекания процесса.
Основные достоинства модели дорожек:
 дает мгновенный снимок того, кто какие действия выполняет;
 дает визуальное представление обменов между действиями и процессами.
 Дорожки можно применять с уровня 3 (перечень сквозных процессов) и далее, поскольку
на этих уровнях отдельные процессы и лежащие в их основе действия могут распределяться
между сотрудниками и структурными подразделениями.
Модель процессов «пять колонок» (уровни 3 и/или 4)
Модель процессов «пять колонок» дает общий вид источника, ввода, вывода и назначения
каждой деятельности и может быть в текстовом виде (т.е. таблица) или в виде блок-схемы
(см. табл. П.1).

Колонки определены так:

1. Источник: исходный пункт действия.
2. Ввод: необходимые ресурсы (документы или информация) для действия.
3. Действие: действия и точки выбора (также должно быть указано, кто выполняет дан-
ное действие).
4. Вывод: результат (документ или информация) действия.
5. Назначение: конечное назначение вывода, созданного действием; может быть архив
или следующее действие.
Основное достоинство модели процессов «в пять колонок» в том, что это лучший способ
текстового описания процессов, когда нет инструментального средства моделирования и
управления процессами.
Кое-кто применяет трехколоночную (ввод, действие и вывод) или четырехколоночную
схему (действие, лицо, документ и система), но они не дают ясной картины связи различных
действий друг с другом, а это один из основных вопросов подготовки моделей.

Совещание на этапе понимания — презентация для стартового совещания

Одной из первых задач совещания на этапе понимания является формирование рамочной
среды для проведения серии дальнейших совещаний. Как правило, это делается в форме пре-
зентации для бизнеса и некоторых членов группы проекта. Ниже приводится возможное со-
держание такой презентации.
1. Повестка.
1.1. Введение.
1.1.1. Как будут проходить практические совещания этапа понимания.
1.1.2. Роли и обязанности участников.
1.1.3. Объем проекта и данного этапа.
1.1.4. Что такое управление бизнес-процессами? (Не все участники понимают это, так что
краткое пояснение или презентация не помешают).
1.2. Согласованный перечень сквозных процессов.
1.3. Матрица выбора процессов организации.
2. Регламент или положение о практических совещаниях.
3. Чего ожидают / на что рассчитывают участники практических совещаний (организа-
тор совещаний должен понять, отличаются ли ожидания участников от запланиро-
ванных, и если да, то внести корректировки).
4. Объем проекта — подтвердить его и довести до понимания каждым участником.
5. Цели проекта — обеспечить понимание цели проекта каждым участником.
 6. Конкретные итоги этапа понимания — обеспечить понимание всеми участниками
ожидаемых итогов по окончании практических совещаний.
7. Возможно, показать несколько картинок инструмента моделирования, который будет
использоваться, с описанием создания моделей и их типов (нет необходимости де-
тальной демонстрации инструмента моделирования, поскольку на практических со-
вещаниях он будет использоваться реально).
8. Повестки отдельных практических совещаний — у каждого совещания должна быть
своя согласованная повестка и формат. Наше предложение:
8.1. Краткое изложение и подведение итогов предыдущих заседаний.
8.1.1. Обсуждение и рассмотрение работ, выполненных после окончания совещания группой
проекта.
8.1.2. Что должно быть сделано после предыдущего совещания.
8.1.3. Проведение заседаний совещаний по обсуждению и моделированию процессов.
8.1.4. Предметные специалисты подводят итоги этих заседаний.
8.1.5. Что нужно сделать вне работы совещаний к следующему совещанию.
8.1.6. Согласование повестки и моделируемых бизнес-процессов, которые будут рассматри-
ваться на следующем совещании.

Руководство по моделированию
При моделировании процессов должны учитываться следующие соображения:
 цели и аудитория модели: перед моделированием нужно определить цель и аудито-
рию данной модели процесса. Часто приходилось наблюдать, что модели процессов
используют больше людей и в более широком диапазоне целей, чем предполагалось
вначале;
 утверждение и руководство: перед моделированием нужно определить, кто будет
утверждать и поддерживать модели процессов. Очень часто после завершения про-
екта приходилось слышать от участников, что если бы они знали, что будут фор-
мально утверждать данные модели процессов, то более активно участвовали бы в
работе;
 общий вид: первый шаг моделирования процессов — определение места данного про-
цесса в общей структуре процессов организации, а затем дальнейшая детализация
процессов. Это даст участникам необходимый ОБЩИЙ вид;
 шаги модели процессов: здесь важно определить четкую последовательность шагов по
разработке, обсуждению, утверждению и поддержке моделей процессов, а также
обозначить роли и обязанности различных людей;
 стандарты и эталонные модели: определить применимые стандарты и эталонные
модели.
Сформулированы следующие принципы моделирования [14]:
 принцип корректности. Модель должна иметь корректный синтаксис и семантику.
Метод должен быть всесторонним и согласованным, а модель соответствовать ему.
Только после этого модель может проверяться на соответствие реальности при по-
мощи средств моделирования, и распространяться среди других специалистов моде-
лирования и бизнес-пользователей. «Строго придерживайтесь метода моделирова-
ния (большей частью)»;
 принцип релевантности. Характеристики следует моделировать, только если они от-
вечают цели модели. Слишком детальное моделирование отвлекает время, ведет к
лишним затратам и запутывает людей. В целом, если модель занимает больше двух
страниц формата A4, моделирование излишне подробно. «Не пытайтесь моделиро-
вать Вселенную»;
 принцип цены выгод. Усилия по сбору данных и созданию модели должны отвечать
ожидаемым выгодам. В целом около 80% выгоды проистекает из 20% затраченных
усилий. Извлечение остальных 20% выгод потребует вложения еще 80% усилий.
«Знайте, когда остановиться»;
 принцип ясности. Модель должна быть понятной, и чтобы ей можно было пользо-
ваться. Модели бизнес-процессов сложны, поэтому разбивайте модели на обозримые
части, которые вкладываются в общую структуру. «Делайте модели проще. Вычур-
ные модели часто запутывают»;
  принцип сравнимости. Инструментальное средство моделирование может быть очень
мощным. Его можно применять различными способами, чтобы получить один и тот
же результат. Реальные выгоды приносит общение. Нужно делиться информацией.
Для этого необходимо принять общий подход к методам моделирования с помощью
инструмента моделирования. «Определите стандарты и следуйте им»;
 принцип систематической структуры. Модели, созданные в различных картинах,
должны быть способны к интеграции. Снова придерживайтесь метода, общих услов-
ных обозначений и создайте и используйте библиотеки общих объектов. «Не изоб-
ретайте колесо. Используйте все, что уже есть в готовом виде».

Журнал вопросов и возможностей. Чрезвычайно важной частью этапа понимания является

выявление и формулировка идей, замыслов, возможностей и вопросов и их регистрация в
журнале вопросов и возможностей. Этот журнал должен вестись на всем этапе понимания (и
других этапах) и содержать следующие сведения:
 номер п/п;
 название процесса;
 описание вопроса;
 последствия (широкие или узкие?);
 приоритет;
 затрагивает ли стратегию, бизнес, организацию, архитектуру (включая соответствие
требованиям законодательства и нормативных актов) или ИТ;
 решение вопроса;
 кратко- или долгосрочный вопрос;
 ответственное лицо;
 вероятные выгоды:
o описание;
o величина (в денежном выражении);
o каким образом извлекаются;
o ограничения;
o предположения/допущения;
o количественное/качественное влияние;
 связываемые с этим затраты.
Приложение E
Этап инноваций. Сверочный список
Данный сверочный список дает общее представление возможных исходных данных, кон-
кретных результатов и шлюзов этапа инноваций.
Возможные исходные данные на входе этапа
С этапа стратегии организации:
 документально оформленная версия видения перспектив, миссии, задач, стратегиче-
ского устремления, целей и стратегии реализации;
 ключевые выделяющие/отличительные факторы организации.
С этапа архитектуры процессов:
 документально оформленная и согласованная архитектура процессов;
 архитектура запуска процессов;
 схема управления выгодами.
С этапа стартовой площадки:
 заинтересованные стороны и лица, определенные в проекте, участвующие в нем или
связанные с ним;
 вовлечение заинтересованных сторон, степень их убежденности и документально
оформленные и согласованные ожидания;
 матрица выбора процессов и исходные метрики;
o перечень согласованных задач процессов;
o матрица ценности процессов;
o управление проектом;
o выгоды проекта и план реализации;
o начальное бизнес-обоснование.
С этапа понимания:
 модели действующих процессов;
 точки отсчета метрик;
 матрица способностей персонала;
 перечень приоритетов для этапа инноваций;
 план проекта (подробный) для этапа инноваций;
 точки отсчета и сравнительные измерения.
Прочие входные данные:
 перечень связываемых проектов для определения синергии и общих областей пересе-
чения
Конкретные результаты на выходе:
 перечень согласованных задач процессов;
 модели и документация новых процессов;
 имитационные модели;
 информация по раздельному учету затрат по типам деятельности;
 информация по планированию ресурсов персонала;
 вовлечение заинтересованных сторон, степень их убежденности и документально
оформленные и согласованные ожидания;
 анализ разрывов процессов;
 обновленная матрица выбора процессов;
 метрики для различных сценариев инноваций;
 часть, относящаяся к выгодам, в анализе выгод/затрат для бизнес-обоснования;
 план проекта (подробный) для этапов персонала и разработки;
 отчет руководству;
 презентация для руководства;
 обновленный план общения/обмена информацией;
 матрица способностей персонала для новых процессов;
 начальные требования бизнеса;
 уточненный и оптимизированный перечень выгод (с этапа реализации ценности);
 распространение результатов.
Возможные шлюзы:
 анализ заинтересованных лиц и сторон;
 понимание масштаба изменений;
  способность организации к переменам;
 принятие BPM организацией;
 техническое обследование;
 вопросы соответствия нормативным требованиям;
 вопросы управления рисками;
 неоправдавшиеся ожидания.

Стартовое совещание с участием руководства на этапе инноваций (см. стр. 71)

Типовая повестка
Цели:
1. отчет о текущем состоянии проекта.
2. Формирование базы для этапа инноваций проекта:
 обеспечение соответствия итогов этапа стратегическим целям организации;
 письменные указания по задачам процессов для различных процессов;
 общие указания по ограничениям, проблемам и срокам.
Итоги
Согласованный письменный перечень:
 задач процессов;
 указаний для этапа инноваций по ограничениям со стороны бизнеса, бизнес-
проблемам и желательным срокам внедрения перестроенных процессов.

Содержание повестки Ответственный

1. отчет о текущем состоянии проекта
 план проекта – на данный момент и на будущее
 результаты на данный момент
2. Рассмотрение объема проекта
3. Инновации бизнес-процессов и их перестройка
Возможности и ограничения существующих систем приложений
4. Указания для этапа инноваций («правила игры»):
 возможности
 ограничения
 люди
 приложения
 культурные аспекты
 проблемы
 сроки (3, 6, 12, 24 месяца)
5. Определение задач будущих процессов – куда должен прийти бизнес с точки
зрения процессов?
6. Как задачи перестроенных процессов увязаны со стратегическими целями?
7. Анализ матрицы ценности процессов
8. Сверочный список показателей успеха проекта, согласованный с руководством,
проверить соответствие показателей успеха с решениями, принятыми на этом совеща-
нии
9. Конкретные результаты проекта для этапа инноваций
10. Прочее

Шаги этапа инноваций

Структура совещаний на этапе инноваций
Этот раздел содержит описание предлагаемой структуры и порядка проведения совещаний
на этапе инноваций.

Проведение практических совещаний

Структура совещаний зависит от многих факторов: размера организации, количества сове-
щаний, числа участников, сложности рассматриваемых процессов — и это лишь некоторые
из переменных факторов. Наилучшее сочетание ролей в достаточно крупной организации и
сложных процессах таково:
 «посредник» — лицо, которое ведет совещания, обеспечивая строгое соблюдение об-
щей направленности и руководящих указаний, а также постоянный учет сроков и
итогов согласно общей направленности;
  «специалист моделирования процессов» — предполагает моделирование процессов в
онлайновом режиме во время совещаний при помощи инструмента моделирования и
управления процессами с проектированием на экран для обозрения всеми участни-
ками. Мы пришли к выводу, что это наилучший способ, поскольку он позволяет ак-
тивно участвовать в обсуждении всех присутствующих. Специалист моделирования
не только создает модели для показа, но и участвует в обсуждении;
 «секретарь» — ведет запись обсуждения, собирает метрики, записывает мысли, идеи,
возможности, вопросы, проблемы, отмечает идеи, изучение которых отложено. От-
дельным членам групп (особенно из бизнес-подразделений) следует поручить изуче-
ние выдвинутых идей с докладом о результатах на совещании, например возмож-
ность усовершенствования может потребовать дальнейшего изучения в плане влия-
ния на другие сферы бизнеса, системы ИТ, поставщиков или клиентов. Секретарь
должен отслеживать выполнение таких заданий, а также вести подробный протокол
во время совещаний. По нашему опыту, секретарь может оказаться очень полезным,
но его необходимость зависит от масштаба и сложности совещаний, так что секре-
тарь нужен не всегда.
Поведение посредника и других членов группы проекта на совещании должно отражать
разницу между совещаниями на этапах понимания и инноваций. Опытный посредник ощу-
щает эту разницу и имеет в виду следующее:
 участники от бизнеса могут чувствовать угрозу процессам и их возможной роли в бу-
дущем из-за предложенных изменений; посредник и участники группы должны де-
ликатно относиться к этим чувствам;
 укладывается ли проблема или предложение в рассматриваемые временные сроки;
 посредник (и участники не из бизнес-подразделений) должны как можно дольше со-
хранять нейтральность при обсуждениях. Участникам от бизнеса должна быть
предоставлена возможность улучшить процессы. Это также даст бизнесу ощущение
сопричастности и владения «своими» идеями усовершенствования процессов;
 посредник должен создать обстановку, в которой можно будет задавать много вопро-
сов. Это достигается тем, что посредник сам много спрашивает, а критику и отрица-
тельные замечания сводит к минимуму и держит под контролем;
 нужно чаще спрашивать «почему?» и «зачем?»;
 со стороны членов группы и участников не от бизнеса не должно быть значительных
разногласий;
 между участниками могут возникнуть острые разногласия по вопросу модификации
или полного изменения процессов. Хотя это хорошо с точки зрения достижения
лучшего результата, посредник должен очень деликатно подходить к таким разно-
гласиям;
 посредник должен оказывать влияние на творческих членов группы и, возможно,
подводить их к высказыванию своих суждений первыми, также обеспечив осталь-
ным участникам возможность высказаться;
 следует избегать излишне детальной информации. Например, если появилась необхо-
димость разработать новую «форму» для бизнеса, ее нужно согласовать, но не
углубляться в подробности строения;
 вклад всех участников от бизнеса получает признание и похвалу;
 в конце концов, именно бизнесу принадлежат варианты новых процессов, а не членам
группы и не посреднику.

Ближайшие перспективы
Ниже приводится типовая повестка совещаний для сценариев проекта на три и двенадцать
месяцев.
Вводная часть
Обратитесь с просьбой к руководителю высокого ранга, чтобы он открыл заседание и
рассказал:
 о поставленных целях;
 о задачах и перспективах совещаний (должно быть согласовано на совещаниях с ру-
ководством);
  об ограничениях, которые нужно учитывать на совещаниях; например, сроки три и
двенадцать месяцев; допускаются ли изменения в приложениях ИТ, каналах дистри-
буции или конфигурациях продуктов.
Последовательность
1. Рассмотрение перечня сквозных процессов, составленного для изучаемой сферы биз-
неса во время совещаний на этапе понимания. Если необходимо, его после этого
можно исправить.
1. Выделение двух высших приоритетов, выбранных во время обсуждения силы и сла-
бостей (сила — это возможности) во время совещаний на этапе понимания. Эти
высшие приоритеты должны находиться на видном месте, к ним нужно постоянно
обращаться и учитывать во время обсуждений на этапе инноваций.
2. Обращение к задачам процессов и целям организации, чтобы они учитывались в но-
вых процессах.
3. После этого есть два способа начать обсуждения инноваций:
o рассмотреть недостатки действующего процесса и отладить его;
o полностью перестроить процесс.
4. Начало творческой созидательной работы. Если целесообразно, на этапе моделирова-
ния процесса закодируйте инновации цветом компонентов модели, выделив отличия
от старого процесса (если применимо), и укажите сроки ввода предложенных усо-
вершенствований. Различия в сроках можно также показать отдельными моделями
процесса.
5. Выделение идей и задач, требующих проверки в связи с реализуемостью. Членам
группы можно после этого поручить снова обратиться к бизнесу и проверить прак-
тическую реализуемость предложений. Результаты такой проверки затем доклады-
ваются группе проекта.
6. На различных стадиях во время практических совещаний важно представление участ-
никами своих предложений. Посредник должен обеспечить, чтобы участники от
бизнеса получили признание и поощрения за свои идеи.
7. Разработка нескольких сценариев новых процессов. Не останавливайтесь, разработав
один сценарий. Первые один-два перестроенных процесса только начинают творче-
ский поток, и именно процессы, инновации которых произошли позднее, оказывают-
ся наиболее творческим и эффективными.
Действия после практических совещаний
Сразу же после совещания группа проекта должна провести изучение моделей на основе
заметок секретаря, сделанных на совещании, чтобы в заметках и моделях отражались все об-
суждавшиеся аспекты, а сами заметки и модели были согласованы друг с другом:
 уточняйте детали, чтобы составить сокращенный перечень возможностей;
 глубже изучите техническую реализуемость вариантов;
 еще раз примените критерии оценки более детально, чтобы убедиться в согласован-
ности;
 на рассмотрение руководство выберите не более трех вариантов;
 составьте план (дальнейшие шаги).
Дальнейшие перспективы
Повестка и вопросы для такого совещания в основном аналогичны совещанию по ближай-
шим перспективам, за следующими исключениями:
1. в того чтобы начать с процессов, разработанных на совещаниях этапа понимания, и
слегка или значительно модифицировать их, начните с «чистого листа».
2. Очевидно, что есть возможность «полностью» переосмыслить режим работы процес-
сов. Нужно рассмотреть радикальные идеи и инновации процессов. Полезно прово-
дить «мозговые штурмы» идей, выходящих за пределы привычного образа мыслей:
o посредник должен призвать участников выдвигать радикальные идеи, и на
этой стадии от группы не должно исходить критики или замечаний; идеи
можно записать и наклеить на доску;
o следующий шаг — попросить участников сгруппировать идеи;
o исключить идеи, не отвечающие критериям, заданным на совещании с участи-
ем руководства для этапа инноваций;
o обсудить достоинства идей по существу.
 3. Эти идеи и предложения можно использовать для разработки нового процесса.
Подготовка совещаний
Важно заранее подготовить членов группы, привлеченных к проведению совещаний на этапе
инноваций. Такая подготовка предусматривает:
 рассмотрение моделей этапа понимания, изучаемых на совещаниях;
 если необходимо, подтверждение аспектов процесса этапа понимания на начальном
совещании;
 обдумывание возможных решений инновационных процессов, чтобы при необходи-
мости посредник мог направлять совещание в нужное русло.
Проведение совещаний
Как начать совещания? Очевидно, что естественно начать с предложения участникам от биз-
неса подумать о новом, более эффективном процессе, который будет отвечать срокам и дру-
гим ограничениям, утвержденным вначале. Иногда такой подход наталкивается на безразли-
чие и не получает ответа.
Другие способы начать процесс более структурировано и четко таковы:
1. Контрольные точки. Если моделируемый процесс является финансовым или контро-
лирующим, можно провести мозговой штурм различных контрольных точек, требу-
емых внутри проекта. Например, в случае процесса выписки квитанций и проверки
счетов контрольными точками могут быть:
o проверка ввода всех данных операторами в систему приложения;
o сбор регистрационных записей всех операций ввода информации в систему
приложения;
o сверка этих регистрационных записей с системой приложения;
o сведение всех регистрационных записей в один отчет;
o сверка регистрационных записей с банковскими проводками, чтобы убедиться
в физическом исполнении банковских операций и правильности банковских
проводок;
o поиск в банковских проводках операций, означающих непосредственное депо-
нирование средств в банк, что должно быть введено в систему приложения;
o отсылка отчетов (регистрационных записей ввода данных или консолидиро-
ванных отчетов) в финансовый департамент для проведения выверки банком;
o проверка, что все отчеты получены финансовым департаментом.
Согласовав контрольные точки, можно будет относительно легко и быстро разрабо-
тать процесс, поскольку уже согласованы основные шаги, которым должен соответ-
ствовать процесс.
1. Критические операции. В случае нефинансового процесса путем мозгового штурма
можно определить перечень критически важных операций, которые тоже можно
написать на доске. И в этой ситуации процесс можно разработать относительно про-
сто и быстро. Всегда подвергайте сомнению критически важные операции; убеди-
тесь в их необходимости.
2. Сопротивление и отстраненность представителей бизнеса. Если вы столкнулись с
такой позицией на заседании, например участники от бизнеса считают, что их про-
цесс (этап понимания) действует прекрасно, и его невозможно улучшить, или просто
не хотят его улучшать, то нельзя начинать с попыток перестроить действующий
процесс. Попросите выдвигать предложения по совершенствованию операций дей-
ствующего процесса, одну за другой, и изучите проблемы и области, в которых мож-
но добиться улучшений. После этого можно разработать новый процесс на основе
выдвинутых идей и предъявить его участникам от бизнеса.

Вопросы для совещаний на этапе инноваций

В этом разделе приводятся наиболее важные вопросы, которые нужно изучить перед пере-
краиванием процессов. Лучше всего обсудить их в начале совещания.
Дальнейшее изложение основано на убеждении, что бизнес-процесс и соответствующие
модели не являются самоцелью, а лишь средством достижения цели бизнеса в конкретных
обстоятельствах. Поэтому перед началом проведения совещаний на этапе инноваций и по-
гружением в моделирование процессов, важно иметь правильный вектор движения и кон-
текст, на котором основано моделирование. Затем эти соображения должны обсуждаться и
четко формулироваться.
Важно понимать, что у каждого есть неявные предположения о возможностях и ограни-
чениях инноваций процессов. Потенциалу совещаний будет нанесен ущерб такими неявны-
ми предположениями, если они не изучены, не обговорены, не поняты и не согласованы.
Вопросник ниже относится только к процессно-ориентированной перестройке, а не к
системно- или организационно направленной перестройке.
Как пользоваться вопросником?
Перед началом этапа инноваций нужно обсудить приведенные ниже вопросы. Важно опре-
делить объем этапа инноваций до проведения совещаний. После этого можно начинать мо-
делирование.
Вопросник-анкета
ОПРЕДЕЛЕНИЕ ОБЪЕМА
1. Каков объем и охват процессов, которые будут перестроены?
Что не входит в сферу и объем?
БИЗНЕС
2. В достижение какой обобщенной бизнес-цели вносят вклад данные процессы (ЧТО?)
3. Какая стратегия должна применяться как основа процессов? (КАК?)
Доверительные отношения с клиентом
Лидерство продукта
Совершенство функционирования
4. Каковы основные движущие силы изменений процессов (ЗАЧЕМ менять?)
ПРОЦЕССЫ
5. Что есть хорошего в действующих процессах?
6. Какие узкие места/проблемы в действующих процессах нужно устранить?
7. Какие лучшие практические методики можно использовать? Это можно сделать на
основе эталонных моделей, идеальных моделей, отраслевой практики и сравнения с
отсчетными точками.
8. Каковы главные усовершенствования, которые можно внести в процессы?
9. Каковы показатели эффективности функционирования/параметры SLA (качество и
количество)?
10. Каковы другие увязанные с процессами метрики — включая соответствующие де-
композиции?
11. Каким образом осуществляется мониторинг процессов и кем, какие переменные мо-
гут использоваться, чтобы отладить процессы?
12. Какие правила/нормативные акты/регламенты должен соблюдать данный процесс
(внутренние и внешние)?
13. Какие значимые интерфейсы у данного процесса с другими процессами?
ОРГАНИЗАЦИЯ
14. Какие структурные подразделения вовлечены в процесс, какие критерии они приме-
няют к процессу?
15. Какой персонал и на каких должностях вовлечен в процесс, и нужно ли это учитывать
на совещаниях инноваций?
ИНФОРМАЦИОННЫЕ СИСТЕМЫ
16. Какие информационные системы включены; какие возможности и ограничения это
привносит?
ДОКУМЕНТЫ
17. Какие результаты/документы должны быть на выходе; должны ли они отвечать ка-
ким-либо особым требованиям (например, правовым)?
Кейс: инновации
Данный кейс проходит через все шаги и предложения из главы 17 и дает пример применения
их в крупной финансовой организации с несколькими тысячами сотрудников, многими отде-
лениями, разбросанными по всей стране. Руководство финансового учреждения поняло, что
движение к процессно-центрированной организации необходимо для ее будущего, и взялось
за программу прививания такого процессно-центрированного взгляда в организации. Руко-
водство было готово поддержать программу значительным финансированием; перед ним
стояла задача добиться существенного продвижения к целям в ближайшие два-три года.
 (Замечание: шаги идут не в том порядке, в каком они описаны главе 17; это показывает,
что шаги схемы должны быть гибкими, удовлетворяя различные потребности организации и
отвечая различным ситуациям.)
Были согласованы следующие движущие мотивы бизнеса:
 необходимость конкурировать на рынке;
 необходимость снизить коэффициент затрат (выручка к расходам), который на тот
момент был выше среднеотраслевого, до значения, значительно ниже среднеотрас-
левого, чтобы получить конкурентное преимущество;
 необходимость увеличить время, которое персонал отделений проводил с клиентами,
а не в административной работе (открывая возможность дополнительных доходов);
 желание строить длительные, глубокие отношения с клиентами;
 улучшение в использовании человеческих ресурсов, повысив удовлетворенность ра-
ботников и обеспечивая стабильное обслуживание клиентов даже при пиковых
нагрузках;
 необходимость выхода на новые рынки.
Для подхода к программе была разработана стратегия (рис. П.10).

Теперь пройдем по итоговым шагам и опишем порядок, которому следовала организация

в подходе к этой программе проектов усовершенствования:
1. Прежде всего, организация взялась за комплекс мер по формированию основ про-
граммы, установив комплекс направляющих указаний и стандартов (архитектура процессов),
что включало:
 выбор инструмента моделирования и управления процессами с возможностью цен-
трализованного хранения процессов;
 договоренность, что все моделирование будет сквозным (из конца в конец);
 соглашение о стандарте и глубине моделирования процессов;
 назначение хозяев каждого процесса;
 стандартизацию процессов по всей организации;
 согласие во всей организации, что «лучшее — враг хорошего» (под этим понималось,
что они не будут добиваться полного совершенства; совершенство — дорогое удо-
вольствие, и не дает выгод, которые оправдывали бы расходы).

Затем были проведены обследования рабочих мест и совещания по документированию

процессов, которые были стандартизованы во всей организации. Собраны идеи инноваций и
усовершенствования процессов. Эти идеи были направлены для изучения и оценки в голов-
ную группу проекта.
2. Проведено сквозное имитационное моделирование, с разными целями и с несколькими
итогами:
 действующие процессы имитировались, чтобы понять раскладку времени, а также
сравнить с существующей занятостью персонала и его загрузкой;
 этот анализ также установил отсчетные измеренные уровни для оценки и измерения
будущих предложений инноваций процессов;
  анализ узких мест и имитации дал дальнейшее понимание упрощений и улучшений
процессов;
 предложенные варианты усовершенствований процессов были проанализированы и
сравнивались друг с другом и с действующими процессами; это способствовало
формулированию оптимальной процессной среды;
 было имитировано планирование укомплектования процессов персоналом в различ-
ных сценариях (анализ переменного объема транзакций помог определить устойчи-
вые уровни обслуживания и дал сведения для работы по планированию персонала);
 было проведено сопоставление и оптимизация профессиональных способностей пер-
сонала в потоке процессов;
 имитационное моделирование обеспечило метод тестирования и оценки новых про-
цессов до их внедрения.
3. Перед внедрением любых новых процессов они оценивались по методике раздельно-
го учета затрат по типу деятельности. Это определило реальные сквозные затраты процесса,
что дало:
 возможность распределить затраты по процессам, которые создавали продукты;
 информацию для более точного и эффективного управления затратами;
 возможность предоставить руководству понимание себестоимости процессов;
 входные данные для установления более точной цены продуктов и услуг, поскольку
можно было точнее рассчитать себестоимость процессов (в случае цены на базе се-
бестоимости);
 возможность провести анализ «что если…», когда это считалось необходимым.
4. Эта информация была введена обратно в анализ предложений по инновациям процес-
сов, а затем в имитационные модели.
5. Указанные выше сведения были помещены в хранилище процессов для документаль-
ного оформления любых изменений, чтобы обеспечить постоянную доступность информа-
ции всему персоналу. Затем информацию (модели процессов) предоставили персоналу путем
размещения на сайте организации.
6. После этого было проведено планирование персонала, определявшее обеспечение
правильного числа подготовленных нужным образом работников в нужное время, чтобы
удовлетворить потребности клиентов или организации. Таким образом достигалась удовле-
творенность персонала, клиентов и организации. Планирование связывалось с пониманием и
анализом:
 объемов транзакций и времени их продвижения по организации, чтобы получить
представление о времени наиболее интенсивной нагрузки в течение дня и наиболее
загруженных днях недели;
 типов поступающих транзакций, временем их поступления и профессиональных
навыков, требуемых для обработки трансакций;
 профессионального уровня отдельных работников и требований обучения и подго-
товки.
Была заполнена матрица — перечень профессиональных навыков — содержащая:
 ранг отдельного профессионального уровня по каждому процессу от 1 до 5, где 1 со-
ответствовало новичку, 5 — профессионалу. Определение уровней профессионализ-
ма было выполнено в ходе собеседований, тестов и обследования функциональных
характеристик персонала и его компетенций, а также с помощью матрицы професси-
ональных навыков;
 требования к обучению для повышения профессионального уровня в сочетании с ти-
пами транзакций и объемами (бессмысленно обучать людей, повышая их умение в
транзакциях, которые встречаются нечасто);
 обработки для каждой транзакции и каждого профессионального уровня, например
сотрудник с уровнем 5 (профессионал) будет быстрее справляться с обработкой
транзакции, чем сотрудник с уровнем 1 («новичок»). Было принято решение относи-
тельно скорости (использование быстро работающих профессионалов) и гибкости
(использование многофункционального персонала);
 понимание планирования персонала и связанных с этим аспектов позволило органи-
зации оптимизировать удовлетворенность сотрудников и комплектование персона-
лом, а также снизить затраты. Такое планирование персонала и прогнозирование
 труда было выполнено централизованной группой для всей организации и по доста-
точно коротким интервалам (скажем, тридцать минут), чтобы при необходимости
персонал был в наличии. Хотя это может показаться огромной работой (и вначале
это действительно было так), на самом деле со временем такой подход упростил
сложный вопрос планирования персонала, особенно когда оно было интегрировано с
решением по распределению работ в рабочем потоке;
 информация планирования ресурсов персонала также дала обратную связь в имита-
ционные модели, которые могут потребовать дальнейшего анализа и отладки.
7. Распределение работ (машина процессов) стало модулем, где осуществлялось внед-
рение результатов планирования и приложение усилий. Работа, приходящая в организацию,
поступала в автоматизированное решение BPM. Модуль распределения работ выбирал
надлежащий процесс и обращался к информации о текущих очередях в обработке и о невы-
полненных работах, а также к матрице профессиональных способностей. Это позволяло
направить конкретную транзакцию на обработку следующему свободному и наиболее ква-
лифицированному (или подходящему) сотруднику.
Это являлось средством управления и контроля организацией своей операционной дея-
тельности. Такое распределение работ и проверка состояния в сочетании с мониторингом
бизнес-деятельности позволяли точно калибровать время согласно циклу процесса, что при-
менялось для отладки/рационализации процессов, как описано на следующем шаге.
8. Последний шаг обеспечивал поддерживаемую устойчивость функционирования.
Именно здесь осуществлялся мониторинг «фактической» обработки транзакций и собира-
лись данные о реальном времени обработки, затратах, объемах и проблемах («узкие места»,
переизбыток укомплектования персоналом). Информация подвергалась постоянному мони-
торингу и анализу, вводилась обратно в имитационное моделирование, учет затрат по типам
деятельности и далее в планирование персонала для уточнения необходимого числа работ-
ников.
Данная информация также использовалась для формирования сведений о показателях
эффективности работы для хозяев процессов, руководства, коллективов работников и персо-
нала.
Результаты. Финансовые результаты данной организации показали значительное сокраще-
ние коэффициента расходов по отношению к выручке (с 70% до 40% за три года). Разумеет-
ся, были и другие выгоды, например повышение удовлетворенности клиентов и персонала и
самый высокий в отрасли показатель времени работы с клиентом.

Типовой анализ разрывов процессов

Анализ разрывов процессов выявляет различия между итогами этапа понимания и этапа ин-
новаций, и должен содержать следующее:
1. Общий анализ влияния изменений процессов на организацию.
2. Варианты внедрения и замечания.
3. По каждому отдельному процессу:
o краткое описание процесса с этапа понимания;
o краткое описание выбранных новых процессов с инновациями;
o сводка основных различий между двумя версиями процессов;
o любые проблемы процессов;
o влияние соответствующих метрик;
o общее обсуждение влияния изменений и замечания.
4. Оценку сформулированного общего влияния.
5. Определенные сроки проекта.
6. Определенное влияние и требования обучения.
7. Выявленные вопросы управления изменениями.
8. Определенное влияние на структуру организации и требования.
9. Риски процессов и внедрения.
Приложение F
Этап разработки
Сверочный список: этап разработки
Данный сверочный список дает общее представление о возможных исходных данных на
входе, конкретных результатах на выходе и шлюзах данного этапа.
Возможные данные на входе
С этапа понимания:
 модели действующих процессов.
С этапа инноваций:
 перечень согласованных задач процессов;
 модели и документация новых процессов;
 имитационные модели;
 разрывов процессов;
 выбранного решения;
 план проекта (подробно) для этапов персонала и разработки;
 уточненный и оптимизированный комплекс выгод;
 начальные требования бизнеса.
С этапа персонала:
 формирование измерений ролей (задач);
 показатели эффективности функционирования;
 документация для обучения.
Прочие входные данные:
 перечень связанных проектов с целью определить синергию и пересечение;
 архитектура предприятия или ИТ.
Конкретные результаты на выходе:
 общее описание решения;
 подробные требования бизнеса;
 документация выбора программного обеспечения;
 технические требования на программное обеспечение и структура;
 разработка и конфигурирование ПО;
 программы-скрипты и результаты тестирования ПО;
 технические спецификации аппаратного обеспечения и его наличие;
 программы-скрипты и результаты тестирования аппаратного обеспечения;
 программы-скрипты и результаты интеграции;
 подробности выявленных выгод (с этапа реализации ценности);
 распространение результатов.
Возможные шлюзы:
 конфигурация разработки и тестирования программного и аппаратного обеспечения
не та же самая, что будет в реальной обстановке;
 анализ заинтересованных лиц и сторон;
 понимание масштаба перемен;
 способность организации изменяться;
 принятие BPM организацией;
 технические трудности;
 трудности с тестированием.
Компоненты автоматизированного решения
Компоненты автоматизированного решения BPM
Мы считаем, что есть девять составляющих — автоматизированных блоков полностью ав-
томатизированного решения BPM (рис. П.11).
Кейс: у нас уже есть все компоненты
Нам приходилось видеть крупные организации, где имелись все девять автоматизированных
компонентов-модулей, но эти организации не понимали, как объединить их в решение BPM,
а иногда не понимали, зачем объединять.
Вывод. Без понимания BPM в руководстве организации, без схемы, опыта и профессио-
нализма BPM автоматизированные компоненты либо не будут применяться, либо использо-
ваться неоптимально.
Означает ли это, что каждое решение BPM должно быть автоматизировано? Конечно,
нет. Степень автоматизации может быть от нуля до почти полной автоматизации. Уровень
автоматизации зависит от потребностей организации.
Автоматизированные блоки рассмотрены ниже более подробно.
1. Средство моделирования и разработки процессов — инструмент моделирования орга-
низацией своих процессов и подпроцессов. Он не требует инструмента технологии
BPM, поскольку моделирование можно выполнить, используя несколько продуктов
Microsoft (или даже карандашом на бумаге, если пожелаете, но это будет дольше и
значительно менее гибко). Технологически оснащенный инструмент моделирования
гораздо эффективнее. Имеющиеся инструменты лежат в широком диапазоне: от про-
стейших неразвитых средств, описывающих процессы в простом формате без связей с
другими процессами до чрезвычайно сложных и развитых инструментов, строящих
связи между процессами, подпроцессами, с общей картиной организации, обобщен-
ными цепочками создания ценности и повторным применением подпроцессов. Все это
осуществляется на основе технологии центрального хранилища на сервере.
Основные достоинства:
 возможность нескольким специалистам моделирования использовать и модифициро-
вать модели в любой момент в любом месте, что сокращает сроки, улучшает согла-
сованность и снижает затраты;
 возможность контролировать модель процесса, например проверять ее корректность,
актуальное состояние и эффективность, улучшая качество и давая больше результа-
тов;
 возможность публиковать модели процессов, чтобы к ним и сопутствующей инфор-
мации можно было обращаться и сверяться с ней (например, шаблоны писем, веб-
страниц, форм заявок). Это приводит к тому, что моделями пользуется больше лю-
дей, качество повышается, а расходы снижаются.
2. Имитационное моделирование. Здесь организация намерена имитировать реализуе-
мость своих процессов, чтобы выявить слабые и узкие места, болевые точки и недо-
статок ресурсов, т.е. можно увидеть, будет ли процесс работать так, как предполагает-
ся. На основе определенных для имитируемого процесса ключевых показателей эф-
фективности (сделанных допущениях) можно взвесить различные варианты и прове-
сти сравнение с отчетными показателями до внесения высокозатратных изменений в
процессы. Имея это в виду, нужно всегда задавать себе следующий фундаментальный
вопрос, относящийся к функционированию перестроенных бизнес-процессов: кто де-
лает, что делает и в какой последовательности? Недостаточно просто описать бизнес-
процессы. Имитационное моделирование дает множество вариантов анализа, позволя-
ющих судить о динамичном взаимодействии между различными процессами.
Основные достоинства:
 возможность увидеть «узкие места» процесса и взаимозависимости процессов и ре-
сурсов, что дает лучшие результаты и снижение затрат;
 возможность сравнить различные процессы по их эффективности и скорости, распро-
странить лучшие методики — улучшение результатов и снижение затрат;
 возможность проверить усовершенствованный процесс и испытать его в различных
сценариях;
 возможность сократить затраты на внедрение и иметь более эффективные процессы.
9. Учет затрат по типам деятельности (ABC). Это полезный сопутствующий инстру-
ментарий для существующих систем учета затрат и себестоимости. ABC позволяет
измерить «успешность» проектов BPM и создает прозрачность понимания и, следова-
тельно, потенциальную возможность контроля затрат. Этот инструмент поддерживает
принятие стратегических решений по затратам и позволяет добиваться долгосрочного
снижения затрат. Способность создавать конкурентное превосходство и использовать
его требует знания «истинных» затрат.
Основные достоинства:
 возможность понять затратную составляющую процессов, что приводит к лучшему
согласованию цены и себестоимости;
 возможность сравнить различные процессы и выявить места для усовершенствова-
ний, что ведет к снижению затрат.
10. Сбалансированная система показателей (BSC). Позволяет определить различные ме-
ры, например основные показатели эффективности (KPI), для измерения процессов.
Такая таблица может использоваться не только для определения количественных мер,
но и для выявления участков бизнес-процессов, в которых нужно проводить измере-
ния и выдавать отчетность. Их можно увязать со стратегическими целями организа-
ции. BSC дает основу для компонента мониторинга бизнес-деятельности (BAM — см.
п. 9), описанного ниже. Например, можно определить меры предполагаемых затрат на
обработку и расклад по времени исполнения процессов. Далее реальные характери-
стики затрат и длительности, полученные в компоненте мониторинга, можно срав-
нить с установленными нормативами.
Основные достоинства:
 возможность увязать процессы и их итоговые результаты с целями организации, до-
стигая улучшения результатов и снижения затрат;
 возможность мониторинга развития процессов и вклада в цели организации, улучша-
ющая результаты и снижающая затраты;
 возможность корректировать цели и определять их воздействие на процессы, повы-
шая маневренность процессов и организации в целом.
11. Модуль процессов (рабочий поток). Система «рабочий поток» — это общий термин
для обозначения модуля или аппарата процессов, который описывает автоматизацию
внутренних бизнес-операций, задания и транзакции, упрощающие и отлаживающие
бизнес-процессы. Модуль процессов — это компонент ПО, выполняющий или обра-
батывающий события. Чтобы исполнять процессы с помощью модуля процессов, ор-
ганизация должна сначала смоделировать свои процессы либо инструментом модели-
рования, поставляемого поставщиком ПО модуля процессов, либо специализирован-
ным инструментом отображения процессов.
Основные достоинства:
 возможность автоматизировать работу, которая поддается стандартизации, что ведет
к снижению затрат и сокращению цикла обработки и повышению качества;
 возможность распределять работы на основе зависимостей и квалификации работни-
ков, что ведет к сокращению цикла обработки и повышению качества;
 возможность персоналу сосредоточиться на более интересной и важной работе, что
дает возможность повысить удовлетворенность людей и улучшить качество.
12. Модуль бизнес-правил (BRE). Обеспечивает маневренность бизнеса организации, не-
обходимую в сегодняшних условиях, поскольку позволяет выводить бизнес-правила
из старых программных прикладных систем и вводить их в BRE, не полагаясь на тех-
нологии с их вечными проблемами «узких мест». Сегодняшние BRE дают возмож-
ность технически сведущему бизнес-аналитику, работающему с бизнесом (а не с ИТ),
очень быстро изменять бизнес-правила. Вместо того чтобы бизнес формулировал из-
 менения правил, а затем передавал их на рассмотрение в подразделение ИТ, которое
разрабатывает техническое задание, дает стоимость, планирует, разрабатывает и те-
стирует реализацию, бизнес-аналитик может самостоятельно разрабатывать и тести-
ровать изменения, обеспечивая гораздо более высокую маневренность бизнесу. Эта
способность реализовывать моментальные изменения должна удерживаться в рамках
политики продвижения продуктов и потребностей управленческого аудита организа-
ции, хотя такая политика может потребовать существенной переработки в результате
новых технологических возможностей.
Основные достоинства:
 возможность автоматизации большего объема работы, что приводит к улучшению ка-
чества и сокращению затрат и цикла обработки;
 возможность проверки и управления бизнес-правилами до ввода каких-либо измене-
ний, что ведет к улучшению качества и сокращению затрат;
 возможность бизнесу осуществлять мониторинг и управлять бизнес-правилами, по-
скольку бизнесу уже не нужно полагаться целиком на ИТ, что ведет к более эффек-
тивным, управляемым и маневренным процессам.
13. Интеграция. Обеспечивает интерфейсный слой между моделями процессов в модуле
процессов и старыми системами приложений организации. Интеграция — суще-
ственный компонент, и если он не учтен на ранних стадиях проекта, это может приве-
сти к неудаче всего проекта. Данный аспект рассматривается в главе 24, где обсуж-
даются возможные шлюзы прохождения проекта.
Основные достоинства:
 возможность внедрять автоматизацию BPM, одновременно сохраняя существующие
системы, что дает значительно больше выгод при ограниченных затратах;
 возможность уменьшить дублирование и несоответствия информации, что ведет к со-
кращению затрат и улучшению качества;
 возможность быстрее вносить изменения, чем при старых традиционных системах,
что ведет к повышению маневренности и существенному снижению затрат.
14. Интегрированная система управления документами. Большинство процессов, осо-
бенно в финансовой сфере, сопровождается бумажными документами. Поэтому при
внедрении автоматизированного решения без сопровождающей интегрированной си-
стемы управления документами организация рискует иметь очень быстрые процессы,
но при этом дожидаться, пока процесс нагонит физическая бумажная работа. С точки
зрения процесса, очевидно, что гораздо лучше иметь сканированные документы, до-
ступные процессу по требованию. Некоторые организации сознательно приняли ре-
шения руководства о внедрении BPM без компоненты управления документами с по-
мощью электронных изображений, поставив под угрозу BPM и не обеспечив ожидае-
мых выгод бизнесу.
Основные достоинства:
 ниже затраты и выше качество обработки документов;
 документы имеются в электронном виде, так что работа может выполняться с элек-
тронной версией, значительно сокращая цикл обработки (не нужно дожидаться по-
лучения бумажной версии документа);
 проще осуществляется отслеживание и извлечение документов, сокращая цикл обра-
ботки и затраты.
15. Мониторинг бизнес-деятельности (BAM). Сбор и анализ процессной информации,
связанной с показателями эффективности, является необходимым требованием
успешного внедрения и оценки мер непрерывной оптимизации бизнес-процессов.
BAM дает реальные меры эффективности, которые можно сравнивать с целевыми
нормативами, определенными в части таблиц сбалансированных показателей. BAM
автоматически выделяет данные об эффективности в процессах организации, особен-
но в процессах, охватывающих несколько систем, делая возможным их анализ. Такая
информация может собираться из различных систем приложений организации, а не
только из модуля (аппарата) процессов. BAM дает сведения, помогающие увидеть
слабые места в работе процессов и оптимизировать циклы обработки. BAM действует
не просто как «система раннего оповещения», предоставляя не только ретроспектив-
ные данные, но и прогностическую информацию для управления бизнес-процессами.
 Отчетность обеспечивается на бумаге или в виде управленческих инструментальных
панелей.
Основные достоинства:
 возможность мониторинга процессов в реальном (или почти реальном) времени и
«спуска» до уровня проблемных участков, что сокращает число проблем и снижает
затраты;
 возможность предвидеть задержки и параметры соглашений о качестве обслуживания
(SLA), которые нельзя удовлетворить, что позволяет предпринимать упреждающие
действия, повышая качество;
 возможность проводить сравнение процессов с конкурентами и отраслевыми стандар-
тами, что должно улучшить результаты.
Названные девять компонентов автоматизации — это предложенные нами средства ав-
томатизации в решении BPM для зрелой в смысле BPM организации, но это не означает
необходимость наличия всех девяти компонентов для успеха проекта. Организация может
решить не использовать первые четыре компонента, а в некоторых ситуациях какого-то ком-
понента может не потребоваться. Ясно, что чем больше число используемых компонентов,
тем выше шансы получить выгоды из проекта. Но «инструмент — это всего лишь инстру-
мент». Если он не используется эффективно, то не решит проблему бизнеса. Это как с по-
купкой саксофона, если не знаешь, как на нем играть.

Пример на рис. П.12 показывает, как компоненты технологий могут работать совместно в
транзакции смены адреса в крупной организации с большим числом старых систем прило-
жений. В данном примере не описывается интегрированный компонент системы управления
документами.
Представьте, что до начала транзакции смены адреса организация смоделировала про-
цесс (возможно, перестроила его, чтобы сделать более эффективным), возможно, выполнила
имитационное моделирование и учет затрат по типам деятельности, а затем установила нор-
мативы процесса по времени и затратам. Эти нормативы будут использоваться в будущем
для сравнения с фактическими показателями.
В данном примере клиент обращается в организацию через один из пунктов контакта
между работниками и клиентами (точки соприкосновения) в левой части рис. П.12 (WAP —
протокол беспроводных приложений, IVR — интерактивный речевой ответ, факс, центр вы-
зовов и т.д.). Этим инициируется процесс смены адреса.
 Данный тип процесса запускает модуль процессов (компонент «рабочий поток») для
планирования, выбора приоритетов и управления обработкой. Модуль процессов «вызыва-
ет» модуль бизнес-правил, чтобы применить к данной транзакции любые бизнес-правила, а
затем вызывает компонент интеграции, чтобы получить доступ к старым системам приложе-
ний, где необходимо обновление. В данном примере есть четыре такие «традиционные» си-
стемы приложений, в которых необходимо обновить адрес. Модуль процессов ведет мони-
торинг транзакции обновления адреса, чтобы проследить ее успешное завершение. Если на
данный момент одна из старых систем приложений недоступна, модуль процессов продол-
жает попытки обновить данные, пока система не окажется готовой. Если эта система так и не
вошла в режим готовности течение определенного периода времени, модуль процессов со-
общает об этом (исключение) соответствующему назначенному супервайзеру или менедже-
ру.
Во время выполнения всех этих действий компонент мониторинга бизнес-деятельности
записывает информацию в библиотеку данных процессов. Именно эти сведения будут фигу-
рировать в сравнении с табличными сбалансированными показателями, т.е. будет выдано
сравнение фактических показателей с установленными нормативами по времени и затратам.
На их основе менеджеры процессов смогут планировать, исследовать и оптимизировать ра-
боту в будущем.
Хотя приведенный пример кажется тривиальным, смена адресов клиентов в крупных ор-
ганизациях может оказаться весьма сложной и подверженной ошибкам процедурой. Часто
это связано с большим числом и разнообразием старых систем приложений в организациях.
Нам приходилось сталкиваться с организациями, где было более тридцати старых систем
приложений, причем продукты клиентов находились сразу в нескольких из них. С точки
зрения клиента после его сообщения организация должна внести изменения во все свои опе-
рации с ним (продукты). Такое «простое» событие смены адреса может привести к суще-
ственному времени обработки, осложнениям и ошибкам, вызывая негодование клиентов.
Приложение G
Этап работы с персоналом
Сверочный список: этап работы с персоналом
Данный сверочный список дает общее представление о возможных исходных данных, кон-
кретных результатах и шлюзах данного этапа.
Возможные исходные данные на входе этапа
С этапа понимания:
 модели действующих процессов;
 матрица способностей персонала;
 потребности в знаниях и информации.
С этапа инноваций:
 перечень согласованных задач процессов;
 модели и документация новых процессов;
 информация планирования ресурсов персонала;
 вовлечение заинтересованных сторон, степень их убежденности и документально
оформленные и согласованные ожидания;
 анализ разрывов процессов;
 план проекта (подробный) для этапа разработки;
 обновленный план общения/обмена информацией;
 матрица способностей персонала для новых процессов;
 уточненный и оптимизированный комплекс выгод.
С этапа разработки:
 общий обзор решения;
 подробные требования бизнеса.
Прочие входные данные:
 политика и руководящие указания в сфере человеческих ресурсов;
 действующие должностные инструкции и роли.
Конкретные результаты на выходе:
 документация стратегии в области работы с персоналом;
 новые ролевые инструкции;
 формирование мер для ролей (задачи);
 показатели эффективности работы;
 анализ разрывов ключевых способностей персонала;
 перестроенная структура организация;
 уточненная кадровая политика;
 документация обучения;
 подробности определенных выгод (с этапа реализации ценности);
 распространение результатов.
Возможные шлюзы:
 негибкая кадровая политика (в области человеческих ресурсов);
 негибкость совета трудового коллектива или профсоюза;
 анализ заинтересованных лиц и сторон;
 понимание масштаба перемен;
 потенциал организации осуществлять перемены;
 принятие организацией BPM.
Приложение H
Этап реализации/внедрения
Сверочный список: этап реализации
Данный сверочный список дает общее представление о возможных исходных данных, кон-
кретных результатах и шлюзах этапа реализации.
Возможные исходные данные на входе этапа
С этапа стартовой площадки:
 исходная стратегия реализации.
С этапа понимания:
 потребности в знаниях и информации.
С этапа инноваций:
 перечень согласованных задач процессов;
 модели и документация новых процессов;
 информация планирования ресурсов персонала;
 анализ разрывов процессов;
 матрица способностей персонала для новых процессов;
 уточненный и оптимизированный комплекс выгод.
С этапа работы с персоналом:
 документация стратегии в области персонала;
 новые ролевые инструкции;
 формирование мер для ролей (задачи);
 показатели эффективности работы;
 анализ разрывов ключевых способностей персонала;
 перестроенная структура организация;
 уточненная кадровая политика;
 документация обучения;
 подробности определенных выгод.
С этапа разработки:
 общий обзор решения;
 подробные требования бизнеса;
 скрипты и результаты тестирования ПО;
 скрипты и результаты интегрированного тестирования;
 подробности определенных выгод.
Прочие данные на входе:
 политика в области человеческих ресурсов — помощь для обучения.
Конкретные результаты на выходе:
 подготовленный и мотивированный персонал;
 планы развертывания, отхода и на случай непредвиденных обстоятельств;
 программы маркетинга;
 стратегия реализация;
 тесты пользовательской приемки бизнеса (UAT);
 выполненные тесты UAT и достигнутые результаты, улучшенные процессы или но-
вые процессы, работающие удовлетворительно, согласно требованиям и нуждам за-
интересованных сторон;
 реализованное решение;
 окончательные подробности определенных выгод (с этапа реализации ценности);
 доведение до соответствующих заинтересованных сторон.
Возможные шлюзы
 не проходят тесты UAT;
 не срабатывают планы развертывания, отхода (возврата в предыдущее состояние);
 обучение не получается или проводится слишком рано;
 анализ заинтересованных лиц и сторон;
 понимание масштаба перемен;
 потенциал организации осуществлять перемены;
 принятие организацией BPM;
 техническое обследование.
Указания по обучению
Данное дополнение содержит описание специфических для BPM аспектов обучения и про-
фессиональной подготовки. Поскольку обучению посвящено множество трудов, и оно силь-
но зависит от целей, аудитории и обстановки, мы не даем полного перечня мероприятий по
организации обучения, а ограничимся лишь особыми аспектами обучения BPM.
Общие указания по обучению
Определите ясные цели и итоги обучения. Нам случалось наблюдать ситуации, когда двух-
дневный курс обучения инструменту моделирования использовался как способ ознакомить
менеджеров проекта с возможностями инструмента (что можно сделать за полдня). Нет нуж-
ды повторять, что менеджеры проектов сильно заскучали и были весьма раздосадованы, ко-
гда поняли это.
Сформируйте аудитории: есть ли смысл разбивать людей на группы согласно предыду-
щему опыту, по опыту работы с BPM/инструментами BPM, профессиональным навыкам,
стажу и т.п.?
Заблаговременно доведите до аудитории цели и ожидаемые итоги. Предоставьте людям
возможность задавать вопросы и давайте обратную связь. Мы были свидетелями случаев,
когда утром людям говорили прийти на обучениe после обеда, ничего не рассказывая о при-
чинах.
Начинайте каждый урок с выяснения ожиданий обучаемых. Напишите их на доске, что-
бы все их видели во время обучения. В начале каждого нового урока узнавайте о продвиже-
нии.
Все процессы нужно, насколько возможно, связывать с ситуацией участников обучения;
это даст им четкое понимание влияния на рабочую обстановку.
Пример: «много» не значит «хорошо»
Всякий раз, когда нам нужно было убеждать людей в важности целей и согласованности
процессов, мы прибегали к следующей процедуре: просили группы по два-три человека смо-
делировать процесс похода в магазин для закупки бакалеи. Мы обратили внимание, что каж-
дая группа делала одну из трех вещей:
1. Составляла длинный список.
2. Рисовала длинную блок-схему с большим числом условных конструкций «если…
то… в противном случае…».
3. Расходилась во мнении о выполнении задания.
Через десять минут мы просили группы показать, что у них получилось. Некоторые с
гордостью предъявляли свои длинные, сложные списки или модели. Другим нечего было
сказать.
Когда мы спрашивали: «какова аудитория и цель данной модели», группы начинали по-
нимать, что так погрузились в моделирование, что забыли задать самые очевидные вопросы.
Эту простую мысль мы подчеркивали, задавая следующий вопрос: «стали бы вы использо-
вать свое описание, чтобы пойти за покупками? Если нет, то почему?» В этот момент лю-
ди осознавали, как важно подумать, перед тем как браться за моделирование. Мы просили
подумать, что бы произошло, если бы им дали три недели на моделирование бизнес-
процессов: это могло бы погубить модели процессов, ничего не добавив бизнесу.
Далее можно рассмотреть различные описания и широкий спектр моделей, символов, ме-
тодов и выражений, которые применяются для моделирования похода за бакалеей. Именно
здесь мы обращали внимание на важность условных соглашений моделирования, чтобы все
модели складывались согласно единым правилам, и их можно было связывать.
Приложение I
Этап реализации ценности. Сверочный список дает общее представление о возможных ис-
ходных данных, конкретных результатах и шлюзах этапа реализации ценности.
Возможные исходные данные на входе этапа
С этапа архитектуры процессов:
 схема управления выгодами.
С этапа стартовой площадки:
 план потенциальных выгод проекта и их реализации.
С этапа понимания:
 точки отсчета и сравнительные измерения.
С этапа инноваций:
 уточненный и оптимизированный комплекс выгод.
С этапа персонала, разработки и реализации:
 подробности определенных выгод.
С этапа устойчивого функционирования:
 мониторинг и максимизация ценности.
Конкретные результаты на выходе:
 реализация и отслеживание выгод;
 распространение результатов.
Возможные шлюзы
 стратегия разработки не обеспечивает выгод;
 стратегия реализации не обеспечивает выгод;
 анализ заинтересованных лиц и сторон;
 понимание масштаба перемен;
 потенциал организации осуществлять перемены;
 принятие организацией BPM;
 техническое обследование.
Матрица отслеживания выгод. Шаблон (табл. П.2).

Выгода — это цель, которую старается достичь проект (например, сокращение времени
обработки).
Мера — это способ измерения выгоды организацией (от заказа до доставки).
Норматив — целевой показатель, которого должна достичь мера (например, два дня).
Крайний срок — дата, к которой выгода должна быть получена.
Важно назначить ответственного менеджера проекта и спонсора. Возможно, что у одной
выгоды будет несколько мер и нормативов.
Приложение J
Этап устойчивого функционирования
Сверочный список: этап устойчивого функционирования
Данный сверочный список дает общее представление о возможных исходных данных, кон-
кретных результатах и шлюзах этапа устойчивого функционирования.
Возможные исходные данные на входе этапа
С этапа стартовой площадки:
 начальный план реализации (будущие «хозяева» процессов).
С этапа инноваций:
 модели и документация новых процессов.
С этапа персонала:
 документация стратегии в области персонала;
 новые ролевые инструкции;
 формирование мер для ролей (задачи);
 показатели эффективности работы;
 анализ разрывов ключевых способностей персонала;
 перестроенная структура организация;
 уточненная кадровая политика;
 документация обучения;
 подробности определенных выгод (с этапа реализации ценности).
С этапа разработки:
 общий обзор решения;
 подробности определенных выгод (с этапа реализации ценности).
С этапа реализации:
 реализованное решение;
 подробности определенных выгод (с этапа реализации ценности).
С этапа реализации ценности:
 получение и отслеживание выгод.
Конкретные результаты на выходе:
 механизмы управления бизнес-процессами, обнаружения и реализации возможностей
усовершенствования процессов;
 управляемые и усовершенствованные процессы;
 мониторинг и максимизация ценности (с этапа реализации ценности).
Приложение K
 Управление изменениями персонала как неотъемлемый атрибут внедрения BPM
 Движущие силы культурных перемен
 Силы культурных перемен дают полезный фон для определения роли руководителей-
лидеров, сотрудников и менеджеров в программе культурных перемен и распределе-
ния конкретных инициатив проекта.
 На рис. П.13, как и в главе 25, показано, на что нужно обратить внимание и к чему
быть готовым.

 Уточнение применяемой терминологии

 НЕОБХОДИМОСТЬ ведет к движению — увеличивает готовность и желание менять-
ся. Возможность сделать будущий успех реальным и осязаемым стимулирует необхо-
димость действовать. Это не должно наводить страх (страх парализует), а вселять
ощущение безотлагательности и неотвратимости перемен.
 ВИДЕНИЕ ПЕРСПЕКТИВЫ задает вектор, направленность, цель и задачу изменения.
Руководители должны верить в него и делом подтверждать свои слова на основе
предлагаемой новой культуры.
 УСПЕХ формирует веру, повышает уверенность в том, новая культура достижима.
Успех должен распространяться быстро и широко. Успех повышает мотивацию.
 ДУХ дает силу — это источник энергии перемен, связанный с динамикой самого про-
цесса перемен. Речь идет о вселении в людей новых сил для прорыва существующих
барьеров, выхода за рамки обычного мышления и для новых свершений.
 СТРУКТУРА требует изменений. На поведение людей будут влиять перемены в раз-
личных аспектах организации. Физические перемены в рабочей среде могут также
включать процесс изменений. Важно мобилизовать всю имеющуюся и потенциаль-
ную готовность к переменам, как в организации, так и в людях.
 СПОСОБНОСТИ к переменам гарантируют их осуществление. Обеспечение этих
способностей повышает уверенность сотрудников. Требуемая способность достигает-
ся путем обучения, образования, промо-информационных кампаний и через личные
достижения сотрудников в проекте.
 СИСТЕМЫ закрепляют изменения. Обратная информация о результатах дает готов-
ность к переменам. Системы анализа эффективности работы, схемы вознаграждений
и распространения информации играют в этом важную роль, гарантируя упрочнение
и укоренение новой культуры.
Приложение L
 Внедрение BPM в организацию
 Группа интересов BPM
 В главе 28 рассмотрено позиционирование BPM внутри структуры организации. Во
многих организациях есть люди, заинтересованные в BPM или даже страстно увле-
ченные им, но им часто трудно убедить руководство предпринять какие-либо струк-
турные шаги по внедрению BPM.
 Один из способов обеспечить формулирование и возможность расширения интересов
BPM внутри организации — сформировать группу интересов BPM. Такая группа мо-
жет свести людей из всей организации (и даже представителей партнеров и клиентов),
чтобы подумать, как BPM может открыть новые возможности для организации.
 Группа интересов должна сформировать интерес BPM и понимание, что такое BPM (и
чем оно не является), какие выгоды оно принесет организации, и какой вклад может
внести каждый сотрудник. У этой группы должны быть четко поставленные цели и
задачи. Она может приводить примеры извлечения организациями преимуществ из
BPM и организовать обмен опытом и идеями между людьми из различных частей ор-
ганизации. Рекомендуется, чтобы группа включала несколько центров внимания, по-
скольку сфера BPM меняется в широких пределах, например технических аспектах,
регулировании и бизнес-аспектах.
 Группа интересов BPM — прекрасный способ зажечь искру интереса в сотрудниках.
Некоторым организациям нужен начальный толчок результаты, чтобы сделать первые
шаги по внедрению BPM.
 Если группа зарождается в проекте BPM, важно чтобы вектор проекта сохранялся на
достижении целей проекта. Рекомендуется, чтобы группу интересов BPM координи-
ровал энтузиаст-спонсор от бизнеса, обеспечивая сохранение нацеленности персонала
проекта на сам проект и достаточное принятие проекта бизнесом.
 Лучший способ сбалансировать разнообразные инициативы и одновременно иметь
общую картину таких инициатив — обеспечить координацию инициатив со стороны
члена Центра совершенствования, как показано на рис. П.14.

Форум BPM
 В этом разделе рассказывается, как скромная инициатива обмена опытом и идеями BPM
между организациями вылилась в общенациональный успех в Голландии, а теперь стар-
товала и в Бельгии (см. www.bpm-forum.org.).
Что послужило толчком Форума BPM
В 2003 году BPM было в центре всеобщего внимания и выдавалось за универсальное маги-
ческое средство, решающее все проблемы организации. Некоторые организации утверждали,
что «BPM — это и есть решение… Какие у вас проблемы?». Многие поставщики смогли
воспользоваться возможностью и начали ребрендинг всех существующих продуктов под
маркой BPM. Потенциальные и фактические пользователи решений BPM теряли ориента-
цию — им нужно было понять, что такое BPM на самом деле, и как его внедрять.
Что такое Форум BPM
Организационный комитет Форума поставил следующую задачу:
Форум стремится быть нейтральным, независимым и внедряющим качество для гене-
рирования и обмена знаниями и профессиональным опытом BPM, методиками, практи-
ческими методами, продуктами и услугами, а также апробированными решениями.
Форум BPM был оазисом и «заправочной станцией» для активных сторонников BPM в
пустыне повседневного управления в организациях, а также удобным местом, чтобы пока-
зать своим коллегам, что BPM может на деле реализовать выгоды бизнеса.
Члены и структура Форума
Форум BPM был задуман для работы своих членов, вместе с ними и через них. Чтобы гаран-
тировать независимость, важно было сбалансировать «вес» членов разных категорий. Разли-
чаются три категории членов: пользователи решений BPM, поставщики решений (услуг и
ПО), научно-исследовательская общественность. В комитете по одному представителю от
каждой из этих категорий. Большая часть деятельности сосредоточена на сайте членов. Фи-
нансирование Форума осуществляется за счет членских взносов корпоративных и индивиду-
альных членов. На рис. П.15 показана структура Комитета советников.

Формы деятельности включают собрания раз в два месяца, поездки на места, конферен-
ции, поддержку сайта, рецензии на книги, создание согласованного словаря BPM и нефор-
мальные мероприятия (например, «на шашлыки с BPM»).
Решающими были признаны следующие факторы успеха:
 нейтралитет и независимость (четкие учредительные принципы);
 баланс между пользователями, поставщиками и учеными;
 мыслить масштабно, начинать с малого: «меньше обещаний, больше дел»;
 общение, общение и еще раз общение;
 баланс критической массы и качества;
 ведение деятельности как на коммерческом предприятии: цели, стратегия, анализ
ССВУ, клиенты, услуги, проекты и процессы.
Обзор условных соглашений моделирования процессов
Здесь описываются предлагаемые условные соглашения при моделировании процессов, в
т.ч.:
 единообразие. Только единое универсальное представление информации в инстру-
менте моделирования создает основу для общения между сотрудниками в различных
бизнес-подразделениях и отделах. Это коммуникативная база важна как часть про-
цессной ориентации, когда сотрудники сообщают друг другу об интерфейсах в раз-
личных областях деятельности, или когда сотрудники из различных отделов органи-
зации работают в проекте совместно. Единообразие применимо к дизайну графики,
условным обозначениям и предполагаемой детализации;
 меньше сложности и больше обозримости моделей процессов. Условные соглашения
в определениях и документации обеспечат получение всеми сотрудниками, участву-
ющими в моделировании в качестве модельщиков или читателей, только значимой
для них и для организации информации. Это особенно важно при выборе моделей,
объектов, символов и атрибутов, а также для формального формирования головной
базы данных. Достоинства меньшей сложности и улучшенной обозримости моделей
особенно заметны при ознакомлении с моделями новых сотрудников и реализации
новых проектов с применением инструмента моделирования и управления процес-
сами;
 возможность повторного использования и сохранность информации. Повторное ис-
пользование и сохранность информации в инструменте моделирования и управлении
процессами — это необходимые требования согласованного видения организацией
процессов и структуры. А такая картина, в свою очередь, — условие толкования и
интерпретации уже хранимой информации;
 согласованность и возможность анализа. Задача состоит в однозначном, полном и
точном анализе информации базы данных по процессам во всех подразделениях и
группах проекта.
Чтобы добиться выполнения этих требований, условные соглашения моделирования
должны быть:
 практичными — сам документ, формализующий условные соглашения, должен быть
полезен при моделировании процессов и давать практическую информацию (не тео-
ретическую) о моделировании с помощью выбранных инструментов и методов в ор-
ганизации;
 доступными — у читателя должен быть простой и интуитивно удобный способ до-
ступа к требуемой информации; лучше всего это обеспечивает ясное и логичное со-
держание и использование перечня диаграмм, глоссария и алфавитного указателя.
Условные соглашения должны быть «пригодны для использования» и не дублировать
учебные пособия или руководства пользователя; они должны давать практические советы и
подсказки для моделирования с помощью выбранного инструмента и управления процесса-
ми в организации.
Элементы условных соглашений моделирования
1. Контроль версий.
2. Содержание.
3. ЧАСТЬ I — ВВЕДЕНИЕ
a. Введение в документ об условных соглашениях:
i. Цель введения условных соглашений.
ii. Кому предназначен документ.
iii. Как пользоваться документом (отдельно по каждой целевой аудитории).
iv. Общий обзор документа (описать каждую главу).
v. Прочая документация, связанная с Условными соглашениями (например,
учебные пособия).
vi. Составители документа.
vii. Порядок внесения исправлений и дополнений в Условные соглашения.
b. Введение в управление бизнес-процессами (BMP):
i. Каково видение BPM организацией.
 ii. Каково текущее состояние BPM в организации (например, соотнести с мо-
делью зрелости BPM) и то состояние, которого стремится достичь органи-
зация.
iii. Каков подход руководства к бизнес-процессам (BPM).
iv. Какие методы/методики/схемы/инструменты применяются.
v. Кто отвечает за BPM в организации.
vi. Каково распределение ролей (функциональных обязанностей) в связи с
BPM? (Перечень задач, обязанностей и полномочий.)
vii. Общий обзор архитектуры процессов в организации.
c. Ведение в методологию и инструментарий моделирования и управления про-
цессами:
i. Какой инструмент (инструменты) выбран (выбраны).
ii. Каковы его основные возможности и характеристики.
iii. Какие факторы в основном предопределили выбор данного инструмента.
iv. Общий обзор инструмента/методологии.
4. ЧАСТЬ II — УСЛОВНЫЕ СОГЛАШЕНИЯ МОДЕЛИРОВАНИЯ
a. Подход моделирования:
i. Моделирование по принципу «сверху-вниз» и «снизу-вверх».
ii. Путь от моделирования процесса до утверждения, опубликования и сопро-
вождения моделей.
b. Методические указания моделирования:
i. Принципы моделирования.
ii. Опыт и уроки, извлеченные из предыдущего моделирования в организа-
ции.
c. Общий обзор типов моделей и объектов моделей:
i. Примеры из реальной практики.
ii. Преимущества типов моделей и объектов моделей.
iii. Если необходимо, перечислите, какие именно модели и объекты.
1. d. Условные наименования:
i. Условные наименования для моделей.
ii. Условные наименования объектов.
iii. Примеры из реальной практики.
e. Графическое отображение:
i. Какая информация о моделях включена.
ii. Макет модели.
iii. Размер и размещение объектов.
f. Элементы моделей и объектов:
i. Элементы моделей и объектов и указание обязательных полей (если пере-
чень слишком длинный, его нужно поместить в приложении).
g. Распространенные ошибки:
i. Часто встречающиеся ошибки, включая примеры из реальной практики; по-
дробный пошаговый метод, позволяющий избежать ошибок или испра-
вить их.
h. Формирование отчетов.
2. ЧАСТЬ III — ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ
a. Установка.
b. Конфигурация и настройка.
c. Структура каталогов.
d. Смена пароля.
3. Глоссарий.
4. Перечень диаграмм (рисунков).
5. Алфавитный указатель.
Сверочный список выбора инструментального средства моделирования и управления биз-
нес-процессами
Опасности при выборе инструментария и управления процессами
Подходящее для организации средство моделирования и управления процессами нельзя вы-
бирать исключительно по его функциональным возможностям или цене, а по пригодности
для целей, в которых организация намерена пользоваться им. При выборе такого инструмен-
тального средства распространены две ошибки (рис. П.16):

1. Напрасная трата денег (завышенная цена): требования, предъявляемые организаци-

ей к инструментарию, достаточно стандартны, но приобретается новейший продукт
с широкими функциональными возможностями. Это приводит к неоправданным
расходам (на приобретение и содержание) и разочарованию пользователей (посколь-
ку для работы с инструментарием требуется интенсивное обучение), но используется
лишь ограниченное число из широкого множества заложенных в продукт возможно-
стей.
2. «Традиционный» (ниже среднего): организация намерена начать с основ, и приобрета-
ет средство, обеспечивающие базовую функциональность. Однако требования со
временем расширяются, и организация обнаруживает, что «традиционное» средство
не отвечает требованиям по функциональности. Это ведет к умножению усилий по
моделированию процессов, недовольству сотрудников и дополнительным затратам
при переходе на другой инструментарий.
Если исходные требования организации скромные, и она намерена начать с простого ин-
струментария, есть две возможные стратегии:
1. Модульный подход: выбирайте инструментарий, который либо можно расширить да-
лее с помощью дополнительных модулей, либо можно сконфигурировать на началь-
ной стадии с ограниченными возможностями, но впоследствии легко переконфигу-
рировать для использования в более широком варианте. Такие дополнительные мо-
дули либо входят в приобретаемый комплекс, либо приобретаются у других постав-
щиков. Необходимо быть внимательным, чтобы инструмент легко масштабировался
с ростом числа пользователей.
2. Тактический подход: выберите инструмент, который отвечает ближайшей цели, и
примите осознанное решение заменить его, когда и если ваши требования расширят-
ся. Важно отдавать себе отчет, что чем больше сил вложено в модели, тем труднее и
дороже будет переход со старого инструмента на новый. Например, придется воссо-
здавать все модели процессов.
Использование сверочного списка
Этот список — общий взгляд на факторы, которые следует иметь в виду при выборе инстру-
ментария моделирования и управления процессами. Его необходимо использовать лишь как
общую ориентировку — каждый процесс выбора индивидуален и имеет свои уникальные
особенности, которые должны выполняться, чтобы полученное решение было оптимальным.
Список относится только к инструменту моделирования и управления процессами, не охва-
тывая выбор автоматизированного решения BPM, которое включает значительно больше
компонент (например, машину процессов — производственный процесс, мониторинг бизнес
деятельности).
Процесс выбора
При выборе инструмента моделирования и управления процессами следует принимать во
внимание следующие аспекты:
1. Определите наиболее важные цели, в которых инструмент будет использоваться в
ближайшие два года, например:
o задача, для которой он будет применяться;
o какие типы моделей будут создаваться;
o тип требуемой документации;
o кто будет пользоваться инструментом;
o сколько людей будут моделировать и пользоваться моделями.
Помните, что большинство инструментов используются дольше и для большего чис-
ла целей, чем изначально предусматривалось. Преобразование всех разработанных
моделей процессов для другого инструмента — многотрудная задача, которая может
потребовать значительного времени и ресурсов. Поэтому важно четко определиться,
нужно ли простое средство проектирования на короткий период или более живучий,
основанный на архитектуре инструмент моделирования и управления.
2. На основе приводимого ниже обобщенного сверочного списка выработайте свой спи-
сок для выбора средства моделирования процессов. Определите общие требования к
инструменту (функциональные, технические и практические), охватив и поддержи-
ваемую методологию. Используйте форму запроса информации и демонстрационные
версии продуктов, чтобы сориентировать требования организации на предлагаемую
на рынке функциональность. Некоторые поставщики продвигают функции, беспо-
лезные для организации; поэтому очень важно сверить предлагаемую функциональ-
ность продукта с реальными выгодами, которые он даст организации. Поинтересуй-
тесь у поставщиков о сильных и слабых сторонах их продукта и решите, какие выго-
ды и ограничения это означает для организации.
3. Изучите ответы на запросы информации, определите подробные требования к ин-
струментарию и сформируйте запрос предложений.
4. Проверьте отзывы о поставщиках и посетите клиентов, пользующихся их продукта-
ми. Проверьте функциональность и поддержку, влияние на организацию, узнайте,
выполняет ли поставщик свои обещания. Полезно задать вопрос: «А купили ли бы
вы этот продукт теперь; стали бы снова работать с его поставщиком?».
5. Проведите пробный прогон перед приобретением продукта: убедитесь, что все пред-
положения и обещания правильные. Привлеките соответствующие заинтересован-
ные стороны (руководство, бизнес-подразделения, финансы, ИТ, пользователей, пер-
сонал BPM, контрагентов, системных архитекторов).
6. В переговорах с выбранным поставщиков всегда имейте про запас один-два варианта
отхода (трудно договариваться о цене, когда остался только один поставщик).
Обобщенный сверочный список
В этом списке пять разделов:
1. Функциональные возможности (по каждому функциональному блоку свои вопросы).
2. Технические аспекты.
3. Практичность, простота и удобство пользования.
4. Цена.
5. Поставщик.
I. ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ
Функциональные модули:
1. Моделирование процессов.
2. Отчеты и аналитика.
3. Управление процессами.
4. Опубликование.
5. Оптимизация.
6. Архитектура предприятия.
7. Раздельный учет затрат по типам деятельности.
8. Автоматизированное решение BPM.
 o Могут ли модули устанавливаться на более поздних стадиях?
o Есть ли масштабируемость в смысле функциональности и глубины моделей?
9. Моделирование процессов:
o Какие типы моделей могут создаваться (блок-схемы, структурно-
организационные схемы, цепочки создания ценности и т.п.)?
o Какие методы моделирования поддерживаются (например, IDEF0, событийные
цепочки процессов и т.п.)?
o Есть ли возможность гиперссылок на документы, страницы HTML и т.п.?
o Как достигается многоуровневое моделирование?
o Какие объекты можно моделировать?
o Какого типа семантические проверки выполняются?
o Какие шаблоны/эталонные модели имеются?
o Есть ли библиотека объектов?
o Обеспечивает ли инструмент повторное использование объектов (например,
при изменении объекта в одной модели изменения видимы всегда, когда
объект используется)?
10. Отчетность и аналитика:
o Какие готовые стандартные отчеты имеются?
o Насколько легко сформировать индивидуальные специализированные отчеты?
o Какая стандартная аналитика имеется?
o Насколько легко выполнить индивидуальный отдельный анализ?
11. Управление процессами:
o Есть общий интегрированный подход к управлению процессами, который об-
разует основу моделей?
o Поддерживает ли система стратегическую, тактическую и оперативную карти-
ну процессов?
o Поддерживаются ли таблицы сбалансированных показателей?
o Можно ли задавать ключевые показатели эффективности (KPI) и вести их мо-
ниторинг?
o Обеспечивает ли инструмент мониторинг бизнес-деятельности (BAM) или ин-
терфейс со средством BAM?
o Обеспечивает ли инструмент соблюдение требований специального законода-
тельства и управление рисками (например, соблюдение требований закона
Сарбанеса-Оксли)?
12. Опубликование:
o Могут ли модели размещаться в Интернет/интранет?
o Насколько легка навигация в опубликованной версии (т.е. работают ли ссыл-
ки/«агрегированные ссылки» в Интернет/интранет так же, как они работают
в инструменте)?
o Насколько легко пользователям понять модели?
o Какие поисковые возможности обеспечиваются?
o Насколько легко индивидуально настроить картинку-макет?
13. Оптимизация:
Имитационное моделирование может дать преимущества, но требует значительных
усилий при разработке. Следует различать три уровня имитационного моделирова-
ния:
o Анализ «что если?» — простая имитация, что произойдет, на основе заданного
комплекса данных.
o Динамическое имитирование — события формируются и обрабатываются по
сконфигурированным параметрам.
o Полнофункциональное имитирование — включает распределение ресурсов и
взаимозависимость с другими процессами.
o Какой анализ обеспечивает инструмент (например, определение «узких
мест»/«точек заторов»)?
o Какие обеспечиваются отчеты имитирования?
14. Архитектура процессов и/или предприятия:
 o Какие имеются архитектурные модели (например, системы и интерфейсы, мо-
дели данных, продукты и услуги и т.д.)?
o Можно ли делать перекрестные ссылки между различными моделями и объек-
тами?
o Какой архитектурный метод используется?
o Какие типы расчетов могут выполняться?
o Какой тип анализа имеется?
15. Учет затрат по типам деятельности:
o Поддерживает ли инструментальное средство учета затрат по типам деятель-
ности
o Есть ли в инструменте интерфейсы с финансовыми системами? Если есть, то
какие?
o Какие типы расчетов можно выполнять?
o Какая отчетность имеется?
o Какая аналитика имеется?
1. Автоматизированное решение BPM:
В этом разделе приводится лишь пара-тройка самых общих вопросов, поскольку вы-
бор автоматизированного решения BPM требует другого, более скрупулезного и
глубокого подхода:
o Имеет ли инструмент машину процессов (workflow — производственный по-
ток заданий) и машину бизнес-правил?
o Имеет ли инструмент интерфейс с системой управления машиной процессов
(workflow) и машиной бизнес-правил (возможность загрузки моделей про-
цессов)? Если да, какие?
o Имеет ли инструмент с интерфейс с интегрированной системой управления
документами? Если да, какие?
II. ПРАКТИЧНОСТЬ
Практичность — простота и удобство пользования:
 Насколько удобен для пользователя инструмент?
 Каково минимально требуемое обучение?
 Поддерживает ли инструмент несколько одновременно работающих пользователей?
 Поддерживает ли инструмент функции перекрестных и агрегированных ссылок?
 Каковы возможности поиска?
 Как обеспечивается управление пользователями инструмента (доступ, пароли, без-
опасность и т.п.)?
 Использует ли инструмент хранилище данных (центральную базу данных)?
Поддержка:
 Какая онлайновая помощь доступна?
 Обеспечивается ли поддержка через стол поддержки? Если да, то сколько стоит?
 Какая поддержка на месте предусмотрена и имеется?
Управление моделями:
 Обеспечивает ли инструмент трассировку изменений, которая показывает, кто и какие
изменения вносил?
 Имеет ли инструмент модуль управления изменениями для определения, отслежива-
ния и разрешения изменений в моделях?
 Позволяет ли инструмент устанавливать авторизацию на индивидуальном и функци-
ональном уровнях?
III. ТЕХНИЧЕСКИЕ АСПЕКТЫ
Аппаратное и программное обеспечение:
 Какая операционная платформа требуется?
 Каковы требования к ПО (проверьте номера версий)?
 Какие варианты базы данных поддерживает инструмент?
 Каковы требования к оборудованию рабочих станций и серверов?
 Каковы требования к инфраструктуре?
 Насколько масштабируемо решение, чтобы справляться с большим количеством дан-
ных, большим числом моделей и большим количеством пользователей?
  Какой эффект будет иметь рост объема данных числа пользователей на производи-
тельность (по времени) инструмента?
Интерфейсы:
 Какие стандарты интерфейса поддерживает инструмент (например, XML)?
 Какие интерфейсы с другими приложениями имеет инструмент (например, системы
управления рабочими потоками, ERP и т д.)?
 Какие стандарты BPM поддерживаются (например, BPML, BPEL)?
 Какие средства импортирования данных, моделей и изображений имеются?
 Какие средства экспортирования имеются?
IV. СТОИМОСТЬ
Цена покупки:
 Какова покупная цена лицензии моделирования?
 Какова покупная цена лицензии администратора?
 Какова покупная цена для просмотра в Интернет и интранет?
 Какова покупная цена дополнительных модулей (например, имитирования, раздель-
ного учета затрат по типам деятельности)?
 Какова скидка при приобретении нескольких лицензий?
Стоимость поддержки:
 Какова стоимость обслуживания или поддержки? Что включено?
 Какова стоимость обучения?
 Какова стоимость консалтинговых услуг?
V. ПОСТАВЩИК
 Как обеспечивается поддержка на местах?
 Каков послужной список поставщика, его репутация? Есть ли рекомендательные
письма-отзывы, подтверждающие это?
 Как проявил себя инструмент в сравнительных тестах?
Аутсорсинг бизнес-процессов (BPO)
Организации испытывают нарастающее давление работать эффективнее, дешевле, быстрее и
более маневренно. И это относится не только к опорным процессам и ключевым продуктам
организаций, а ко всем процессам, даже процессам обеспечения/сопровождения. Большин-
ство организаций едва справляются с вызовами, стоящими в плане конкурентоспособности
основных процессов, не говоря уже о вспомогательных. Именно здесь открывается возмож-
ность аутсорсинга процессов организации третьей стороне. При нынешнем состоянии техно-
логии (безопасность Интернета, широкополосная связь, веб-сервисы и распространяющаяся
по всему миру компьютерная грамотность) — это уже больше, чем просто привлекательный
вариант, по крайней мере, касательно вспомогательных процессов организации.
Причины аутсорсинга
Следующие причины заставляют организации серьезно рассматривать возможность аутсор-
синга:
 нехватка профессиональных знаний в области лучших процессных методик — отно-
сится к аутсорсингу вспомогательных процессов, функционирующих неэффективно.
Обычно это связано с тем, что процессы не анализируются и не совершенствуются;
 нехватка технического профессионализма и необходимых инвестиций — относится к
организациям с устаревшими системами ИТ, которым необходима существенная мо-
дернизация или замена. С учетом ограничений на инвестиции в ИТ, особенно для
вспомогательных процессов, аутсорсинг выглядит сильным решением;
 возможность сосредоточиться на опорных процессах с аутсорсингом вспомогатель-
ных процессов. Это позволит менеджерам сосредоточить внимание, силы и имею-
щиеся инвестиционные средства на опорных процессах;
 снижение затрат. Если сокращение затрат — единственный побудительный мотив, он
не должен быть единственной причиной аутсорсинга.
Критерии при рассмотрении поставщика аутсорсинга бизнес-процессов
Рассматривая возможность аутсорсинга бизнес-процессов, следует принять во внимание
следующие критерии:
 специализированный профессионализм в процессах;
 возможность наращивания по объему и масштабирования по срокам;
 возможность добавлять дополнительные услуги;
  итоговая стоимость (включая начальные организационные затраты) и ценовая гиб-
кость;
 уровни обслуживания и связанные с ними штрафы за несоблюдение согласованных
уровней;
 гибкость изменения договоров и условий;
 приложения ИТ (гибкость и функциональные возможности);
 послужной список поставщика аутсорсинга бизнес-процессов, как зарекомендовал
себя у существующей базы клиентуры.
Посетите объекты существующих клиентов выбранного вами поставщика, чтобы удосто-
вериться в его способности выполнять свои обещания относительно гарантируемых уровней
обслуживания. Аутсорсинг бизнес-процессов — это не просто ввод данных.
Предварительные условия аутсорсинга
В идеале в организации должны быть выполнены следующие предварительные условия аут-
сорсинга бизнес-процессов:
 должны быть определены и поняты метрики процессов; эти метрики должны быть ре-
алистичны;
 процессы должны быть уже отлажены. Аутсорсинг неэффективного процесса, по всей
вероятности, приведет к продолжению неэффективного процесса поставщиком аут-
сорсинга;
 сформируйте план для работников, которые на данный момент выполняют данные
процессы (их придется переводить на другую работу в организации или у поставщи-
ка аутсорсинга);
 пересмотрите бизнес-модель и определите любые возможности бизнеса, которые мо-
гут появиться в результате аутсорсинга;
 разработайте бизнес-обоснование и планирование проекта, охватывающие не только
процессы, подлежащие аутсорсингу, но и влияние на другие бизнес-процессы в ор-
ганизации. Процессы, переданные в аутсорсинг, должны давать вклад в реализацию
новой стратегии и целей организации.
Категории поставщиков аутсорсинга бизнес-процессов
Среди наиболее типичных поставщиков аутсорсинга:
 компании ИТ;
 специализированные компании по процессам (например, специалисты по обработке
предоставления кредитов);
 специализированные отраслевые компании (например, поставщики решений автома-
тизированных систем расчетов АСР);
 офшоры (один из вышеуказанных типов или их сочетание).
Альтернатива аутсорсингу — инсорсинг
Веяние последних 5–10 лет в области крупномасштабного аутсорсинга — возвращение ком-
паниями процессов, которые были в аутсорсинге, внутрь организации. В большинстве слу-
чаев это происходит в результате осознания, что эти процессы на самом деле являются
опорными, например колл-центр дает ценную обратную связь с клиентами.
Некоторые компании с особенно эффективными и продуктивными процессами делают
еще один шаг вперед и предлагают обслуживание другим организациям.
Важные методологии BPM
В данном разделе рассмотрены основные модели и методологии BPM.
BPM складывалось в течение длительного времени. Сегодняшнее представление о BPM
— результат слияния трех основных течений, независимо развивавшихся многие годы. Эти
основные течения связаны с:
1. Мышлением бизнес-процессов: начиная с первой «волны» научного управления, в ко-
тором бизнес-процессы рассматривались как операции на конвейере, и заканчивая
второй «волной» — реинжинирингом бизнес-процессов.
2. Автоматизацией: от истоков автоматизации вычислений и расчетов до попыток авто-
матизировать рабочий поток. С распространением Интернета и связанного с ним ПО
(например, веб-сервисов) стало возможно пересечение границ организаций.
3. Мышлением категориями качества: от инспектирования до включения качества как
неотъемлемой части повседневной деятельности (например, комплексное управле-
 ние качеством — TQM — и kaizen), а также измерение управления качеством
(например, шесть сигм).
Смит и Фингар (Smith, Fingar 2002) так описывают третью волну, где автоматизация,
бизнес-процессы и управление качеством объединились:
Третья волна BPM — это синтез представления процессов и технологий совместной
деятельности, который устраняет преграды на пути исполнения намерений руковод-
ства. BPM, таким образом, является слиянием теории управления, комплексного управ-
ления качеством, шести сигм, бизнес-инжиниринга и общего системного мышления с
современными технологиями.
Первая волна: научное управление
Научное управление символизирует наиболее существенный подход к процессам в первой
волне. В начале ХХ века Адам Смит (Adam Smith) и Фредерик Тейлор (Frederick Taylor) вве-
ли понятие научного подхода к работе бизнес-процессов, особенно на производстве. Адам
Смит в своей книге «Разделение труда» (The Division of Labor — первый том труда «Благо-
состояние народов», Wealth of Nations, 1909–1914) описал возможный рост производитель-
ности, при котором каждый работник выполняет конкретное специализированное задание.
Фредерик Тейлор (1911) ввел понятие научного управления, где он опирался на изучение
интервалов и передвижений, чтобы определить «единственный лучший способ» выполнения
задания.
В обоих подходах проводилось четкое различие труда работника и менеджера-
управленца. Менеджер «думает», а работник «исполняет». Это также приводит к четкому
различию между конструированием, производством и контролем качества. Более того, оба
автора рассматривали работников скорее как автоматы, а не как индивидуальности. Такие
подходы имели сильный крен в сторону:
 стандартизации;
 специализации;
 оптимизации;
 централизации.
Первый сборочный конвейер Генри Форда в большой степени основывался на этих кон-
цепциях. Проблема же в них заключалась в монотонности труда и появлении на начальном
этапе безработных, чьи профессиональные навыки уже не требовались. Более того, работни-
ки не были заинтересованы в конечном результате, и их заинтересованность не поощрялась.
Многие административные и служебные процессы вначале формировались на тех же ос-
новах, что и сборочный конвейер. Со временем стало складываться понимание, что боль-
шинство (если не все) административных и служебных процессов фундаментально отлича-
ется от труда на сборочном конвейере, и подход к ним должен быть совсем другим. Это по-
нимание и привело к позиции, на которой мы находимся сегодня.
Вторая волна: общий обзор BPR
Что это значит
BPR обозначает реинжиниринг бизнес-процессов. В своей книге Reengineering the
Corporation Хаммер и Чампи (Hammer, Champy, [28]) определили BPR как «фундаменталь-
ное переосмысление и кардинальную перестройку процессов организации с целью добиться
коренного улучшения эффективности в затратах, обслуживании и быстроте».
В начале 1990-х годов BPR набрал огромный ход и основывался на представлении, что
административные процессы нельзя сравнить с подходом Тейлора к производству, где у
каждого работника было своя небольшая задача, а конструирование и управление осуществ-
лялось специалистами, а не самими работниками.
В чем состоит главный подход
Дейвенпорт и Шорт (Davenport, Short [13]) выделяли пять следующих шагов в подходе BPR:
1. Разработку видения перспективы бизнеса и целей процессов.
2. Определение перестраиваемых бизнес-процессов.
3. Понимание и измерение действующих процессов.
4. Определение «рычагов» — средств ИТ.
5. Разработку и построение прототипа новых процессов.
Часто называют и шестой шаг — адаптацию структуры организации и модели корпора-
тивного руководства к вновь разработанным первичным процессам.
Хаммер и Чампи [28] выделили следующие типичные характеристики проекта BPR:
 1. Несколько заданий объединяются в одно. Слишком часто процесс выполнялся избы-
точным числом работников (например, каждый рабочий затягивал один винт на сбо-
рочном конвейере), что приводило к длительным периодам наладки.
2. Работники принимают решения. Разделение между исполнением и принятием реше-
ний исчезало, а такое различие приводило к задержкам и низкой удовлетворенности
сотрудников.
3. Шаги процесса выполняются в естественной последовательности. Зачастую процес-
сы описывались как последовательная цепочка операций, которые должны выпол-
няться одна за другой. Естественный порядок шагов процесса позволяет выполнять
операции параллельно и существенно сократить цикл обработки.
4. У процессов есть несколько версий. Гибкость можно обеспечить, исполняя процессы
в зависимости от конкретных обстоятельств, а не за счет массово-обезличенного
подхода.
5. Работа выполняется в наиболее целесообразном месте. Чтобы сократить время и
расходы, можно сократить необязательные передачи работ из рук в руки.
6. Сокращение проверок и контроля. Это достигается наделением полномочиями работ-
ников и повышением их подотчетности и ответственности за свои действия.
7. Минимизация сверок. Сверки и согласования не создают добавочной стоимости, их
можно минимизировать, сократив количество передач работы из рук в руки и число
операций.
8. Менеджер ситуации является единым пунктом контакта. В случае сложной дея-
тельности назначение отдельного менеджера обеспечивает единый пункт контакта
между сложными процессами и клиентом.
9. Преобладание централизованной/децентрализованной деятельности. ИТ позволяют
организациям сэкономить на масштабах за счет централизации, в то время как при-
нятие решений децентрализовано на уровне бизнес-подразделений.
Третья волна: Смит и Фингар
Смит и Фингар [68] написали свой труд по необходимости, поскольку во мнениях о том, как
организации будут конкурировать в ХХI веке, существовала сумятица. Они утверждали:
…мантра реинжиниринга — не автоматизируйте, уничтожайте — дает толчок глу-
бокому уважению и приводит к появлению эффективных средств продуктивного приме-
нения имеющихся активов бизнеса и технологий. Это возможность появляется сейчас,
поскольку лишь недавно сформировались методы и технологии полного обеспечения
управления процессами в определенном здесь смысле.
Эти авторы описали новый способ работы по мере применения организациями развитых
технологий и нового образа мышления, работы и конкурирования. Они утверждали, что
процессы — уже не просто набор действий; для них характерен сквозной характер и дина-
мичность, реагирование на потребности клиентуры и меняющиеся рыночные условия, ши-
рокая распределенность и специализация настройки с пересечением границ внутри и между
компаниями, зачастую процессы охватывают разрозненные технологические платформы.
Процессы также носят длительный характер (например, процесс заказ-доставка-оплата-
отнесение средств) и, по крайней мере, частично автоматизированы. Более того, их трудно
сделать видимыми. Во многих организациях бизнес-процессы неявные и неосознанные. Они
не оформлены документально, а подсознательно вкраплены, и закостенели в совместной ис-
тории организации, а если уж и оформлены документально, то документация и определения
поддерживаются независимо от сопровождающих их систем.
Смит и Фингар описывают влияние новой технологии и как оно реализуется:
BPM — это синтез представления процессов и технологий тесной совместной деятель-
ности, который устраняет преграды на пути исполнения намерений руководства…
Впервые в истории бизнеса этот синтез дает возможность компаниям осуществить
свое вечное желание — управлять бизнес-процессами маневренно и своевременно… Кар-
динальный прорыв состоит в использовании «исчисления процессов» для определения их
цифрового представления, основы новых корпоративных информационных активов.
«Процессные данные», основанные на открытых стандартах описания процессов, поз-
воляют менеджерам эффективно применять в управлении процессами как старые, так
и новые технологии.
 Одно из основных достоинств книги этих авторов — описание того, как с приходом но-
вого образа мышления старые правила (читай: запреты) уже не применяются, и становятся
возможными фундаментально новые способы работы и управления. Например:
Старое правило Необходимо сделать выбор между постепенным усовершенствованием
и кардинальным реинжинирингом

Разрушение Управление циклом процесса в течение срока существования

Новое правило Отсутствуют разрывы

Мы настоятельно рекомендуем всем, кто использует управление бизнес-процессами,
узнать и применять эти новые правила («возможности»).
Общая схема, предложенная в этой книге, является руководством по формированию и
реализации нового способа работы, включающего как процессы, так и управление ими.
Управление качеством по МОС (ISO) 9001:2000
Материал воспроизводится с разрешения Центрального секретариата МОС с сайта Между-
народной организации стандартизации (ISO): www.iso.org
Что означает управление качеством
ISO (МОС) обозначает Международную организацию стандартизации — неправительствен-
ный орган, членами которого являются национальные институты стандартов каждой из
стран-участниц.
Основной подход
МОС разработала свыше 15 тыс. стандартов в широком диапазоне отраслей. Один из веду-
щих стандартов, относящихся к бизнес-процессам, называется ISO 9001:2000 и представляет
собой обобщенные требования (т.е. применим к любой организации). Данный стандарт регу-
лирует управление качеством во взаимодействии между организацией и ее клиентами, глав-
ным образом, между предприятиями. К нему относится:
 соблюдение требований качества клиента;
 выполнение требований действующего законодательства и нормативно-правовых ак-
тов;
 повышение удовлетворенности клиента;
 обеспечение постоянного усовершенствования работы при достижении этих целей.
Следует отметить, что ISO 9000 относится к стандартам процессов, а не продуктов.
ISO 9001:2000 определяет требования к системе управления качеством для любой орга-
низации, которая намерена продемонстрировать свою способность последовательно предо-
ставлять продукт, отвечающий требованиям клиента и действующего правового регулирова-
ния, и нацелена на повышение удовлетворенности клиента.
Принципы
Серия стандартов ISO 9001:2000 включает формулировку принципов управления качеством,
которые улучшают функционирование организации:
 клиент в центре внимания;
 лидерство;
 вовлечение персонала;
 подход;
 системный подход к управлению;
 постоянное совершенствование;
 подход к принятию решений на основе реальных фактов;
 взаимовыгодные отношения с поставщиками.
Шаги
МОС определила шаги реализации стандарта ISO 9001:2000 — системы менеджмента каче-
ства (СМК):
1. Определите цели, которые нужно достичь.
2. Установите, чего хотят от вас другие.
3. Получите информацию о семействе стандартов ISO 9000.
4. Примените семейство стандартов ISO 9000 в вашей системе управления.
5. Получите направляющие указания по конкретным вопросам системы менеджмента
качества.
 6. Определите ваше текущее состояние и выясните разрывы между вашей системой ме-
неджмента качества и требованиями стандарта ISO 9001:2000.
7. Выделите процессы, необходимые для поставки продуктов клиентам.
8. Разработайте план по ликвидации разрывов, выявленных на шаге 6, и разработайте
процессы, выделенные на шаге 7.
9. Реализуйте этот план.
10. Проводите регулярные внутренние проверки с целью оценки.
11. Решите, нужно ли доказать соответствие требованиям; если нужно, переходите на
шаг 12, если нет — на шаг 13.
12. Проведите независимый аудит.
13. Продолжайте совершенствовать бизнес.
МОС не выдает свидетельств о соответствии организациям, которые отвечают требова-
ниям ISO 9001:2000. Сертификация производится независимо от МОС, хотя МОС и разраба-
тывает стандарты и руководства, чтобы содействовать правильной методике деятельности по
сертификации.
Управление качеством: Kaizen
Что это значит
Kaizen (Кайдзан) — это прекрасный подход к вовлечению организации в процессное мыш-
ление. Такое мышление должно включаться в должностную инструкцию каждого сотрудни-
ка. Kaizen — это японская концепция, предусматривающая постепенное поэтапное совер-
шенствование на трех уровнях: руководства, коллективов сотрудников и отдельных сотруд-
ников. «Kai» означает «меняться» или «модифицировать», а «Zen» — «хорошо» или «пра-
вильно».
По сравнению с BPR Kaizen нацелен на постепенные небольшие улучшения, исходящие
от самих сотрудников, и его порог внедрения ниже.
Принципы
Принципы концепции Kaizen:
1. Коллективный труд.
2. Личная дисциплина.
3. Укрепление морального духа.
4. Кружки качества.
5. Предложения по рационализации.
Подход
Группы качества играют важную роль в концепции Kaizen. Группа качества — это неболь-
шая группа работников, которая сосредоточена на улучшениях на своем рабочем месте с
особым вниманием к затратам, продуктивности и технике безопасности. В большинстве слу-
чаев группы качества — дело добровольное, и возглавляют их не менеджеры отделов, а кто-
то из работников.
Масааки Имаи (Masaaki Imai, [44]) выделил следующие шаги групп качества:
1. Выбор темы или проблемы.
2. Понимание текущей ситуации.
3. Постановка цели улучшения.
4. Анализ факторов и измеряемых показателей.
5. Отчет о результатах.
6. Предупреждение рецидива (возврата к старому).
7. Разработка глубинного познания и направлений на будущее.
Управление качеством: шесть сигм
Значение
Сигма — буква греческого алфавита, используемая в статистике для измерения отклонения
данного процесса от совершенства. Шесть сигм означает 3,4 бракованных изделий на мил-
лион, т.е. безотказность 99,9997%. Цель шести сигм — повысить прибыль путем снижения
количества дефектов и повышения удовлетворения клиентов. Это предусматривает система-
тический и аналитический процесс определения, предвидения и решения проблем. «Шесть
сигм» все больше становится методом работы.
Методология «шесть сигм» была разработана компанией Motorola в середине 80-х годов,
и первоначально применялась в производственной сфере; но сегодня находит все более ши-
рокое распространение в сервисных организациях (например, в финансовых учреждениях).
Шаги методологии «шесть сигм»
Методология «шесть сигм» включает следующие шаги:
1. Определение — определить предполагаемое усовершенствование, создать общую
модель процесса и установить, что важно для клиента.
2. Измерение — установить точку отсчета для эффективности действующего процесса и
выявленных проблемных областей, а также составить сжатое описание проблемы.
3. Анализ — провести корневой анализ выявленных проблем, сверить его с имеющими-
ся данными и предложить тестированные решения.
4. Улучшение — выполнить пилотную реализацию и внедрить предложенные решения,
которые должны устранить или смягчить выявленную корневую проблему.
5. Контроль — оценить внедренное решение и исходный план, обеспечить устойчивость
решения, встраивая решения в стандарты.
Концепции методологии «шесть сигм»
Ключом в подходе шести сигм являются следующие концепции (см. сайт www.ge.comпо со-
стоянию на 15 августа 2005 года):
Решающий аспект качества Самые важные для клиента характеристики

Дефект Клиент не получает того, что он хочет

Потенциал процессов Что может обеспечить ваш процесс

Вариации Что видит и ощущает клиент

Устойчивость работы Обеспечивает согласованные предсказуемые процессы для

улучшения того, что видит и ощущает клиент

Разработка для методоло- Разработка с целью отвечать потребностям клиента и каче-

гии «шесть сигм» ство процессов
Кто осуществляет методологию «шесть сигм»
В методологии «шесть сигм» определены различные уровни профессионализма:
 зеленый пояс получают прошедшие базовую подготовку;
 черный пояс присваивается главам коллективов;
 черный пояс «мастера» у того, кто надзирает за обладателями черного пояса.
Строгая методология «шесть сигм»
Философия «ничего лишнего» зародилась на фирме Toyota в 40-х годах. Ее целью было по-
стоянное совершенствование и удовлетворенность клиента, сокращение отходов, затрат и
сроков разработки при одновременном сохранении способности своевременно поставлять
качественные товары. Вместе с подходом «точно вовремя» эта философия вызвала огромный
интерес в производственных отраслях. В последние годы она набирает темпы в администра-
тивных отраслях и отраслях услуг, особенно в сочетании с подходом «шесть сигм», и таким
образом стала известна как «строгие шесть сигм».
Основные принципы
Строгая методология «шесть сигм» нацелена на решение следующих проблем:
 неверное определение требований рынка и клиентов;
 разработка продукта, которая основана не на требованиях клиента, а на удобстве в из-
готовлении/производстве;
 перепроизводство (особенно в силу негибкости процессов);
 складские запасы;
 дефекты;
 ожидание;
 деятельность, не создающая добавочной стоимости;
 транспортировка или перемещение без необходимости;
 неэффективность.
Применение методологии «шесть сигм»
«Шесть сигм» следует применять:
 если проблемы обычные и трудно распознаваемые;
 если неизвестны причины ошибок;
  в сложных ситуациях с множеством переменных.
«Шесть сигм» отлично укладывается в схему, описанную в этой книге, и рассматривается
как подмножество нашей общей схемы.
Когда НЕ стоит применять «шесть сигм»
«Шесть сигм» требует убежденности и упорства всех сотрудников организации, начиная с
высшего руководства, так что если этого нет, данную методологию не стоит даже затевать.
«Шесть сигм» требует также значительных вложений в обучение и последующую про-
грамму подготовки; если финансирование не предоставлено, бесполезно пытаться внедрить
методологию наполовину.
«Шесть сигм» и наша общая схема
Как было сказано выше, «шесть сигм» — полезный и заточенный подход к повышению ка-
чества. Но это всего лишь часть общих аспектов, требуемых в проекте BPM или в процесс-
но-центрированной организации. Основные недостающие элементы:
 согласование со стратегией организации;
 архитектура процессов, в т.ч. согласование с архитектурой процессов и ИТ, а также
методические указания для процессов, что формирует основу для последующих мо-
делей процессов;
 фундаментальное изменение (или реинжиниринг) бизнес-процессов, особенно в слу-
чае изменения в стратегии или слияния/присоединения;
 применение инструментов автоматизированного BPM и инструмента моделирования
и управления процессами;
 неотъемлемые атрибуты проекта BPM, т.е. управление изменениями персонала,
управление проектом и лидерство; им принадлежит особо важная роль в случае ин-
новационной перестройки процессов, а не простой рационализации;
 сквозной характер процессов с пересечением границ организации; тогда как при тра-
диционном подходе «шесть сигм» может быть собрано слишком много информации,
чтобы адекватно справиться с ней.
Кое-кто утверждает, что эти аспекты можно включить в проекты «шесть сигм». Наше
глубокое убеждение: любой метод или схема должны быть полными и комплексными, и не
оставлять важнейшие элементы на откуп мудрости и прозорливости менеджеров проекта.
Поэтому «шесть сигм» и наша схема взаимно дополняют друг друга, при этом привноси-
мая ценность «шести сигм» состоит в следующем:
 твердая нацеленность на качество и его осознание;
 строгость измерений качества и данных;
 механизм выявления ошибок процессов и решений.
Покажем теперь, как будет проходить проект, если «шесть сигм» включится в нашу схе-
му, на примере проекта операционной инициативы:
 этап стартовой площадки — отправная точка. Здесь определяется объем и цель про-
екта: шаг Определение в методологии «шесть сигм» способствует этому, выявляя
участки с наибольшим числом ошибок и наибольшими возможностями в плане
улучшений. Предварительный анализ данных и ошибок полезен в качественных и
количественных наводках, и не дает полагаться на интуицию и отдельные примеры;
 этапы стратегии организации и архитектуры процессов общей схемы можно не вы-
полнять полностью; они лишь служат источником информации для справок и свер-
ки. Сохраняется необходимость согласования со стратегией организации, поскольку
это дает цели и формирует среду процессов. На этих этапах «шесть сигм» не приме-
няется;
 как только проект стартовал, на этапах понимания и инноваций можно пройти шаги
Измерение, Анализ и Улучшение. В общем, некоторые шаги этапов понимания и ин-
новаций могут быть проделаны в рамках подхода «шесть сигм», включая анализ
корневых проблем. Особое внимание следует уделить шагам, связанным с общением
и обменом информацией, вовлечением заинтересованных сторон и решениям по ин-
новациям. Шаги нашей схемы помогут участникам выйти за пределы общепринятого
мышления и разработать новые процессы или воспользоваться автоматизацией BPM;
 на этапах персонала, разработки и реализации ценности рекомендуется воспользо-
ваться шагами общей схемы, чтобы обеспечить согласование и увязку персонала,
 процессов и ИТ. Шаг Контроль в методологии «шесть сигм» можно применить для
мониторинга выгод, обеспечения контроля устойчивости и управления процессами;
 неотъемлемые атрибуты — управление проектом, управление изменениями персона-
ла и лидерство — играют ключевую роль в успехе любого проекта BPM, как и в
успехе проекта «шесть сигм»/BPM. Следует иметь в виду, что проект BPM сильно
зависит от того, насколько хорошо управляется проект BPM и его влияние на бизнес,
а не от применения наилучшего решения или методологии.
Подводя итоги, можно сказать, что BPM заключается в управлении постоянным усовер-
шенствованием процессов в организации. Речь идет о формировании архитектуры бизнес-
процессов, корпоративном руководстве процессами, способности управлять изменениями в
организации, устойчивом функционировании процессов и повышении зрелости BPM, наряду
с прочими аспектами. «Шесть сигм» может стать отличной стратегией вмешательства в слу-
чае проблемы совершенствования бизнес-процессов. Вот почему мы считаем «шесть сигм»
полезным подмножеством общей схемы.

Библиография
3. Ahern, D. M., Clouse, A. and Turner, R. (2004). CMMI Distilled: A Practical Introduction
to Integrated Process Improvement, 2nd edn. Addison-Wesley.
4. Blatter, P. (2005). Learning from manufacturers and industrialization. Presented at
theIQPC BPM Conference, Sydney, April 2005.
5. Bloem, J. and van Doorn, M. (2004). Realisten aan het roer, naar een prestatiegerichte
Governance van IT. Sogeti Nederland.
6. Blount, F. (1999). Changing places: Blount and Joss. Human Resources Monthly, Decem-
ber.
4. Burlton, R. T. (2001). Business Process Management. Sams Publishing.
5. Cavanagh, J. (1999). Australia’s most admired. Business Review Weekly, 15 October.
6. Chibber, M. L. (undated). Leadership. Sri Sathya Sai Books and Publications Trust.
7. Collins, J. (2001). Good to Great. Random House.
8. Cope, M. (2003). The Seven Cs of Consulting, The Definitive Guide to the Consulting Pro-
cess. FT Prentice Hall.
9. Covey, S. (1989). The Seven Habits of Highly Effective People. Simon & Schuster.
10. Curtis, B., Alden, J. and Weber, C. V. (2004). The Use of Process Maturity Models in Busi-
ness Process Management. White Paper. Borland Software Corporation.
11. Davenport, Th. H. (2005). The coming commoditization of processes. Harvard Business Re-
view, June, 83 (6), 100–108.
12. Davenport, Th. H. and Short, J. E. (1990). The industrial engineering information technolo-
gy and business process redesign. Sloan Management Review, Summer.
13. Davis, R. (2001). Business Process Modelling with ARIS, A Practical Guide. Springer.
14. DeToro, I. and McCabe, T. (1997). How to Stay Flexible and Elude Fads. Quality Progress,
30(3), 55–60.
15. Drucker, P. (1991). The new productivity challenge. Harvard Business Review, November–
December.
16. Fisher, D. M. (2004). The Business Process Maturity Model. A Practical Approach for
Identifying Opportunities for Optimization. Available online
athttp://www.bptrends.com/resources_publications.cfm (accessed 17 March 2005).
17. Gartner (2005). Delivering IT’s Contribution: The 2005 CIO Agenda. EXPPremier Report,
January.
18. Gerstner, L. V. Jr (2002). Who Says Elephants Can’t Dance? Harper Business.
19. Goldsmith, J. (1995). Fortune, 12 April.
20. Gray, B. (1989). Collaborating: Finding Common Ground for Multiparty Problems. Jossey-
Bass Publishers.
21. Hakes, C. (1996). The Corporate Self-Assessment Handbook, 3rd edn. Chapman and Hall.
22. Hamel, G. and Prahalad, C. K. (1994). Competing for the Future. Harvard Business School
Press.
23. Hammer, M. (1993). Fortune, 4 October.
24. Hammer, M. (1994). Fortune, 22 August.
25. Hammer, M. (1995). Fortune, 12 April.
 26. Hammer, M. and Champy, J. (1990). Reengineering work: don’t automate, obliterate. Har-
vard Business Review, July.
27. Hammer, M. and Champy, J. (1993). Reegineering the Corporation, a Manifesto for Busi-
ness Revolution. Harper Collins Publishers.
28. Harmon, P. (2003). Business Process Change. Morgan Kaufmann.
29. Harmon, P. (2004). Evaluating an Organisation’s Business Process Maturity. Available
online at http://www.bptrends.com/resources_publications.cfm (accessed 17 March 2005).
30. Harmon, P. (2005a). Service orientated architectures and BPM. Business Process Trends,
22 February.
31. Harmon, P. (2005b). BPM governance. Business Process Trends, 8 February.
32. Harper, P. (2002). Preventing Strategic Gridlock: Leading Over, Under and Around Or-
ganizational Jams to Achieve High Performance Results. CAMEO Publications.
33. Hawley, J. (1993). Reawakening The Spirit in Work. Berrett-Koehler Publishers.
34. Hriegel, R. and Brandt, D. (1996). Sacred Cows Make the Best Burgers. Harper Business.
35. Kaplan, R. and Norton D. (1996). The Balanced Score Card, Translating Strategy into Ac-
tion. Harvard Business School Press.
36. Kaplan, R. and Norton, D. (2004). Strategy Maps: Converting Intangible Assets into Tangi-
ble Outcomes. Harvard Business School Press.
37. Keen, P. (1997). The Process Edge. Harvard Business Press.
38. Koop, R., Rooimans, R. and de Theye, M. (2003). Regatta, ICT implementaties als uitdaging
voor een vier-met-stuurman. ten Hagen Stam.
39. Kramer, N. J., Kramer, T. A. and de Smit, J. (1991). Systeemdenken.
40. Lewin, K. (undated). Frontiers in group dynamics. Human Relations Journal, 1.
41. Lewis, L. (1993). Tandy Users Group Speech 1993 Convention, Orlando, Florida.
42. Luftman, J. N. (2003). Assessing strategic alignment maturity. In: Competing in the Infor-
mation Age: Align in the Sand (J. N. Luftman, ed.), 2nd edn. Oxford University Press.
43. Masaaki Imai (1986). Kaizen: The Key to Japan’s Competitive Success. McGraw-
Hill/Irwin.
44. Masaaki Imai (1998). Kaizen. McGraw-Hill Professional Book Group.
45. Maull, R. S., Tranfield, D. R. and Maull, W. (2003). Factors characterising the maturity of
BPR programmes. International Journal of Operations & Production Management, 23 (6), 596–
624.
46. McCormack, K. P. (1999). The Development of a Measure of Business Process Orientation.
Presented at the European Institute for Advance Studies in Mangement: Workshop on Organiza-
tional Design. Brussels, Belgium, March 1999.
47. Miers, D. (2005). BPM: driving business performance. BP Trends, 5 (1).
48. Mutafelija, B. and Stromberg, H. (2003). Systematic Process Improvement using ISO
9001:2000 and CMMI. Artech House.
49. Neely, A., Adams, C. and Kennerly, M. (2002). Performance Prism: The Score Card for
Measuring and Managing Business Services. FT Prentice Hall.
50. Nelis, J. and Oosterhout, M. (2003). Rendement uit processen. Informatie, May (available
online at www.informatie.nl).
51. Nelson, M. (2003). Enterprise Architecture Modernization Using the Adaptive Enterprise
Framework. The Mercator Group.
52. Newsletter for Organizational Psychologists, 1995.
53. Nohria, N., Joyce, W. and Roberson, B. (2003). What really works. Harvard Business Re-
view, July.
54. Oxford University Press. (2004). Oxford English Dictionary: The definitive record of the
English language. Retrieved 5 January 2006, from http://dictionary.oed.com
55. Paulk, M. C., Curtis, B., Chrissis, M. B. and Weber, C. V. (1993). The Capability Maturity
Model for Software, Version 1.1 (No. CMU/SEI-93-TR-24). Software Engineering Institute.
56. Pol, M., Teunissen, R. and van Veenendaal, E. (2002). Software Testing, A Guide to the
TMap®. Pearson Education.
57. Porter, M. (1980). Competitive Strategy: Techniques for Analyzing Industries and Competi-
tors. Free Press.
58. Porter, M. (1985). Value Chain, Competitive Analysis: Creating and Sustaining Superior
Performance. Free Press.
 59. Pritchard, J.-P. and Armistead, C. (1999). Business process management — lessons from
European business. Business Process Management Journal, 5 (1), 10–32.
60. Rosemann, M. (2005; unpublished). 22 Potential Pitfalls of Process Management.
61. Rosemann, M. and de Bruin, T. (2004). Application of a holistic model for determining BPM
maturity. In: Proceedings of the AIM Pre-ICIS Workshop on Process Management and Information
Systems (Actes du 3e colloque Pre-ICIS de l’AIM), Washington, DC, 12. December 2004 (J. Akoka,
I. Comyn-Wattiau and M. Favier, eds). AIM.
62. Rosemann, M. and de Bruin, T. (2005). Towards a business process management maturity
model. Proceedings of the 13th European Conference on Information Systems (ECIS 2005), Re-
gensburg, 26–28 May 2005. ECIS.
63. Rummler, G. A. (2004). Serious Performance Consulting. International Society for Perfor-
mance Improvement and ASTD.
64. Rummler, G. A. and Brache, A. P. (1995). Improving Performance. Jossey-Bass Publishers.
65. Scheer, A.-G., Abolhassan, F., Jost, W. and Kirchmer, M. (2003). Business Process Change
Management. Springer.
66. Smith, A. (1909–1914). Wealth of Nations. The Harvard Classics.
67. Smith, H. and Fingar, P. (2002). Business Process Management — The Third Wave. Me-
ghan-Kiffer Press.
68. Smith, H. and Fingar, P. (2004). Process Management Maturity Models. Available online
at http://www.bptrends.com/resources_publications.cfm (accessed 23 July 2005).
69. Spanyi, A. (2004). Business Process Management is a Team Sport: Play it to Win! Meghan
Kiffer.
70. Stace, D. and Dunphy, D. (1996). Beyond the Boundaries. McGraw-Hill.
71. Taylor, F. W. (1998). The Principles of Scientific Management. Dover Publications (reprint
of 1911 original).
72. Treacy, M. and Wiersma, F. (1997).The Discipline of Market Leaders. Perseus Books.
73. Van de Berg, H. and Franken, H. (2003). Handboek Business Process Engineering. BizzDe-
sign B. V.
74. Van den Berg, M. and van Steenbergen, M. (2002). DYA©: Speed and Alignment of Busi-
ness and ICT Architecture. Sogeti Nederland.
75. Van der Marck, P. (2005). Scoren met uw Waardecreatie (Scoring with your value proposi-
tion), at www.managementsite.nl/content/articles/298/298.asp.
76. Wagter, R., van den Berg, M., Luijpers, J. and van Steenbergen, M. (2002). DYA©: Dynam-
ic Enterprise Architecture: How to Make it Work. Sogeti Nederland.
77. Walton, M. (1986). The Deming Management Methods. The Berkley Publishing Group.
78. Ward, J. and Peppard, J. (2002). Strategic Planning for Information Systems. John Wiley &
Sons.
79. Wertheim, E., Love, A., Peck, C. and Littlefield, L. (1998). Skills for Resolving Conflict. Er-
uditions Publishing.
80. Wheatley, M. J. (1994). Leadership and the New Science. Berrett-Koehler.
81. Zachman, J. A. (1987). A framework for information system architecture. IBM Systems
Journal, 26 (3).
1 Этот закон был принят Конгрессом США после серии скандалов и разоблачений махи-
наций в руководстве крупных фирм, в первую очередь — энергетического гиганта, компании
Enron, и телекоммуникационной компании Wordlcom, которые с помощью бухгалтерских
уловок раздували прибыль и поддерживали высокую цену акций. Закон ужесточает учет и
отчетность, но вызывает дополнительные, иногда значительные, затраты на соблюдение тре-
бований закона. — Прим. науч. ред.
2 Система Базель II представляет собой международные высокие стандарты банковской
деятельности, отличающиеся сложным подходом к оценкам операционных и кредитных
рисков. — Прим. науч. ред.

https://sberbankvip.alpinadigital.ru/reader/book/831