Картина процессов организации – самый общий вид структуры организации с точки зрения процессов. На рис. 14.7 приведен пример страховой фирмы. Выделение или группировка процессов обычно показываются на трех уровнях:

1. Стратегические процессы – обеспечивают постоянное выполнение нижележащими процессами своих задач/показателей.

2. Опорные процессы – представляют основные (главные) области бизнес-деятельности организации.

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

Диаграмма картины процессов служит нескольким целям:

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

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

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

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

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

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

Лучше получить эту информацию на практическом совещании, типовая повестка и подход которого приводятся в Приложении Е.

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

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

• моделей данных, их опорных принципов и логики;

• основных приложений и соответствующих интерфейсов, их опорных принципов и логики;

• основного промежуточного ПО, его опорных принципов и логики;

• основных платформ, их опорных принципов и логики;

• основных сетей, их опорных принципов и логики.

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

Кейс: «неправильная» архитектура

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

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

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