Текст книги "Управление бизнес-процессами. Практическое руководство по успешной реализации проектов"

Несколько наиболее часто встречающихся рисков этапа выработки стратегии приведены в табл. 13.2.

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

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

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

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

• соответствие перестроенных или вновь разработанных процессов целям организации и ее стратегии;

• увязывание процессов с тем, как ведется (или должен вестись) бизнес и способность предоставить продукты/услуги потребителям;

• увязывание процессов с архитектурой ИТ и приложениями, поскольку ИТ должны поддерживать настоящие и будущие процессы;

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

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

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

Кейс: неуклонно реализовывать стратегию

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

Вывод. Обеспечьте явную формулировку стратегии и ее применение при конструировании и мониторинге процессов. Архитектура процессов – хороший способ добиться этого.

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

Кейс: 1 + 1 + 1 = 1

Крупная организация решила отладить внутренние процессы. Отдел ИТ наложил на свою деятельность процессы, которые нужно было поддерживать, используя инструмент моделирования «1» и ИТ-подход. Бизнес-подразделение описало процессы с помощью инструмента моделирования «2» и действовало методами, соответствующими этому инструменту. Финансовое подразделение стремилось отобразить процессы, имеющие финансовое воздействие, в целях соблюдения закона Сарбанеса-Оксли, используя еще один инструмент моделирования. Очевидно, что при таком подходе нельзя получить существенных и долгосрочных результатов:

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

• нет никакой увязки между различными моделями;

• сомнительно, чтобы описания процессов поддерживались со временем;

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

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

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

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

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

Но в отношении архитектуры справедлива одна суровая истина {52}:

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

В центре внимания данной главы – архитектура процессов, но многие положения, относящиеся к этому этапу, также применимы и к архитектуре предприятия.

Говорят, что если спросить десять архитекторов, то можно получить десять разных определений архитектуры. Поэтому, чтобы не придумывать свое определение, мы перечислим характеристики, составляющие хорошую архитектуру (в духе Вагтера и др. {77}):

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

• должна быть основа для разработки и внедрения процессов организации;

• процессы должны соотноситься со стратегией организации и стратегическими целями;

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

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

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

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

Методическое руководство по процессам – это отображение общих принципов на область процессов. Примерами методических руководств по процессам являются стандарты, методы, инструкции, политика и выбор инструментария. Руководство должно давать конкретные указания по разработке процессов (и последующим разработкам ИТ), и имеет тактическое значение (например, конструкция бизнес-процессов выполняется независимо от структуры организации).

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

Мы следуем таким архитектурным принципам {77}:

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

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

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

• архитектуру можно развивать, постоянно наращивая ее;

• в некоторых обстоятельствах оправданно несоблюдение архитектуры; мы называем это «клапаном скороварки» и рассматриваем на шаге 6 ниже.

Перечислим конкретные результаты на выходе этого этапа:

1. Документально оформленная и согласованная архитектура процессов.

2. Стартовая структура проекта.

3. Картина процессов организации.

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

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

1. Сценарий проекта BPM (см. выше). Выбранный организацией сценарий BPM оказывает серьезное влияние на интенсивность и критичность этого этапа:

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

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

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

• сценарий «вне поля зрения»: имеющаяся информация оценивается. Возможно, возникнут уточняющие вопросы. Документация архитектуры процессов не исправляется или исправляется очень ограниченно.

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

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

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

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

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

3. Сфера и нацеленность архитектуры. Перед тем как сформулировать архитектуру, важно определиться с уровнем «амбициозности», т. е. решить, что войдет в сферу архитектуры и будет в ее фокусе. Одно из ключевых решений, принимаемых здесь, начать ли только с архитектуры процессов (обычно в сценариях «вне поля зрения» и «пилотный проект»), или моделировать всю архитектуру предприятия (обычно в сценарии «рулевой»).

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

Показанные на рис. 14.4 шаги применяются в создании архитектуры процессов и рассматриваются ниже.

На рис. 14.5 показаны соответствующие продукты/услуги, а также и методические руководства и модели, используемые для получения информации о стратегии и бизнесе.

Информация, которую необходимо получить:

• общие стратегические цели (показатели) и принципы, определенные на этапе стратегии организации, доработанные/обновленные при необходимости;

• соответствующие методические руководства (инструкции) по бизнесу (продукты и услуги) и модели;

• соответствующие модели и руководства организации.

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

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

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

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

• типология клиентов, опорные принципы и логика;

• типы расценок и скидок, опорные принципы и логика;

• типы партнеров (включая поставщиков) и каналов распределения, опорные принципы и логика.

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

Предлагаются следующие способы получения этой информации:

• получение перечней продуктов, клиентов, партнеров и прайс-листов;

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

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

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

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

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

• методические руководства (инструкции) по процессам;

• модели процессов;

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

Кейс: крайний случай правила 80/20

Компания по производству программного обеспечения испытывала трудности в доведении до своих клиентов принципов обслуживания, которых она придерживалась при оказании сервисных услуг. Бизнес-архитектору потребовалось свыше пятидесяти страниц, чтобы описать основные процессы этого решения, так что никто не имел о нем четкого представления. Нам удалось дать общую картину 95 % основных процессов на трех простых диаграммах и четырех страницах текста (т. е. менее 10 % исходного текста). Когда мы побеседовали с бизнес-архитектором, он указал, что не были описаны некоторые исключения. Однако бизнес-подразделение пришло в восторг от того, что могло легко объяснить структуру своего продукта. С исключениями поработали в других формах.

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

Методическое руководство по процессам – это общие методические указания, которые необходимо сформулировать для процессов. Они включают:

1. Принадлежность процесса (кто хозяин).

2. Масштаб процессов: сквозные или относящиеся к функции/организационной единице.

3. Выбор метода моделирования.

4. Выбор инструмента моделирования и управления процессов.

5. Метод руководства процессами.

6. Аутсорсинг процессов, т. е. когда организация принимает решение об аутсорсинге процессов. Если такое решение принято, важно определить:

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

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

• минимальные критерии, которые должны быть выполнены (например, безопасность, соглашения об уровне обслуживания – SLA);

• что еще нужно принять во внимание (например, привлеченный персонал).

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 говорят на одном языке.