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