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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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