Кейс: 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. Сфера и нацеленность архитектуры. Перед тем как сформулировать архитектуру, важно определиться с уровнем «амбициозности», т. е. решить, что войдет в сферу архитектуры и будет в ее фокусе. Одно из ключевых решений, принимаемых здесь, начать ли только с архитектуры процессов (обычно в сценариях «вне поля зрения» и «пилотный проект»), или моделировать всю архитектуру предприятия (обычно в сценарии «рулевой»).