Всего за 449 руб. Купить полную версию
Модели процессов
Архитектура процессов также должна содержать общее графическое представление процессов. Хороший способ получить такую визуализацию – составить диаграмму картины процессов организации и перечень сквозных процессов.
На рис. 14.7 дается картина процессов организации и более подробный перечень сквозных процессов.
Картина процессов организации
Картина процессов организации – самый общий вид структуры организации с точки зрения процессов. На рис. 14.7 приведен пример страховой фирмы. Выделение или группировка процессов обычно показываются на трех уровнях:
1. Стратегические процессы – обеспечивают постоянное выполнение нижележащими процессами своих задач/показателей.
2. Опорные процессы – представляют основные (главные) области бизнес-деятельности организации.
3. Вспомогательные процессы (обеспечения/поддержки). На этом уровне находятся процессы, которые обеспечивают опорные процессы организации.
Диаграмма картины процессов служит нескольким целям:
• используется для описания процессов организации штатному персоналу и заинтересованным лицам;
• ее следует поместить на самом видном месте во всей организации и, возможно, на внутреннем портале (некоторые организации используют эту диаграмму как домашнюю страницу внутреннего сайта);
• способствует достижению понимания высшим руководством, должностными лицами и персоналом основной деятельности, операций и приоритетов организации с точки зрения процессов, обеспечивая нацеленность на BPM внутри организации.
Однако все это работает, лишь когда общая картина содержит сущностную информацию, принята и используется по всей организации.
Преимущество получения картины процессов в том, что это не только общая модель уровня организации, которую можно применять для увязки процессов нижних уровней. Она также позволяет вовлекать в моделирование руководство. Это дает менеджерам организации возможность сформулировать критически важные зоны процессов, на которых они захотят сконцентрироваться, а также содействует тому, что все основные высшие руководители, заинтересованные лица и участники проекта BPM говорят на одном языке.
Перечень сквозных процессов
Для каждой из групп, выделенных на картине процессов организации, нужно сформировать перечень сквозных процессов. На этапах понимания и инноваций каждый сквозной процесс из этого списка описывается более подробно (и называется моделью сквозного процесса и подробной моделью процесса).
Лучше получить эту информацию на практическом совещании, типовая повестка и подход которого приводятся в Приложении Е.
При разработке этих моделей очень полезно уловить различные метрики, связанные с бизнес-подразделением организации и процессами, – например, определить число работников, занятых в каждом процессе или группе процессов, соответствующий объем продаж и обслуживающих транзакций и т. п. Это поможет сориентировать группу процессов в выборе процессов или участков бизнеса для начала таких последующих этапов схемы, как понимание и инновации.
Шаг 3. Получение нужной информации, принципов и моделей технологий
На данном шаге нужно получить подробные сведения по необходимым «информационным» аспектам (которые относятся к данным и приложениям), а также по аспектам «поддерживающих» технологий (промежуточное ПО, платформы и сети) – рис. 14.8. Мы имеем в виду общие обзоры:
• моделей данных, их опорных принципов и логики;
• основных приложений и соответствующих интерфейсов, их опорных принципов и логики;
• основного промежуточного ПО, его опорных принципов и логики;
• основных платформ, их опорных принципов и логики;
• основных сетей, их опорных принципов и логики.
Наш опыт подсказывает, что самая крупная проблема встраивания архитектуры ИТ в архитектуру предприятия – наличие в подразделении ИТ большинства организаций огромного числа инструментов и приложений. Поэтому нужно суметь сосредоточиться на принципах и основных вариантах выбора.
Кейс: «неправильная» архитектура
Подразделение ИТ одной организации решило внедрить архитектуру предприятия и выдало ее в виде более чем семидесятистраничного технического описания. Когда им задали вопрос о следующих шагах, они сказали, что хотят, чтобы высшее руководство утвердило и в приказном порядке ввело эту «архитектуру». Однако им пришлось признать, что руководство вряд ли разберется в таком документе, не говоря уже о его утверждении. Они осознали, что нужно разработать архитектуру принципиально иным способом: скорее продвигаемую бизнесом, чем наоборот. Разработчики поставили бизнес во главу угла, что привело к созданию полноценной и принятой организацией архитектуры.
Вывод. Крупная проблема архитектуры процессов состоит не в ее формулировании, а в том, чтобы добиться убежденности людей, которые сами захотят использовать такую архитектуру.
Более того, существенно, что ИТ поддерживают цели, стратегию и бизнес, и именно поэтому целесообразно уже иметь архитектуру процессов и бизнеса до выстраивания архитектуры ИТ. Но если разработка архитектуры началась с архитектуры ИТ, нужно внимательно следить за сохранением поддерживающей роли ИТ для требований бизнеса.
Шаг 4. Консолидация и сверка
На этом шаге вся информация консолидируется и сверяется. Часто данный шаг оказывается наиболее проблемным, потому что именно здесь сходятся все противоречивые приоритеты и требования, и именно здесь все они должны быть разрешены. Например, бизнесу может быть нужна гибкость, а подразделению ИТ – стандарты и единообразие.
Один из способов консолидации накопленной информации – сопоставить различные архитектурные модели друг с другом. Например, сочетание организационно-структурных схем и процессов дает карту-схему организационных взаимосвязей (рис. 14.9).
Схема организационных взаимосвязей
Схема организационных взаимосвязей, приведенная на рис. 14.9, в общем виде показывает взаимосвязи и протекание процессов между различными подразделениями и отделами внутри организации. Такая схема дает организации возможность увидеть нестыковки в ходе выполнения процессов. В этом разрезе особенно полезна картина возможного распределения сквозных «клиентских» процессов по структуре организации, что может быть причиной затяжек и ошибок. Светло-серый прямоугольник на рисунке представляет организацию, а все, что не попадает в него, приходит извне организации.
Пример нестыковки процесса также приведен на рис. 14.9. Центр обработки вызовов реализует и вырабатывает руководящие инструкции по кредитованию для организации, отдел взыскания занимается сбором неоплаченных в срок сумм. На этом рисунке нет обратной связи между опытом отдела по взыскиванию сумм относительно эффективности методических инструкций и центром обработки вызовов, чтобы при необходимости подправлять правила кредитования. Если инструкции по кредитованию неудачны, центр обработки вызовов не получит обратной связи.
Лучший способ выработать такую схему – провести практическое совещание со всеми заинтересованными сторонами, при этом:
• используя цели и стратегию организации в качестве отправной точки;
• внося все разнообразные требования и взгляды заинтересованных сторон;
• выявляя взаимосвязи и противоречия между этими требованиями;
• обсуждая противоречия и находя пути их разрешения; здесь проблема – снова выйти из замкнутого пространства мышления и набраться смелости, чтобы принимать решения с мыслью о будущем, вместо того чтобы застрять в настоящем;
• ранжируя требования;
• обсуждая разрывы в процессах и конфликты (включая пути эскалирования на более высокие уровни полномочий);
• подготавливая планы мероприятий для устранения нестыковок и противоречий (включая пути эскалирования);
• предоставляя окончательные выводы соответствующим руководителям, четко обозначив связь со стратегией и целями организации и указывая, как сформулированная архитектура будет содействовать их осуществлению;
• добиваясь окончательного утверждения.
Шаг 5. Обмен информацией
Как уже говорилось, хорошая архитектура – это архитектура, которая понимается, поддерживается и применяется в качестве основы для деятельности и принятия решений в организации. Полезно в данном контексте донести архитектуру и ее выгоды до максимально большого числа людей, которых это касается. Это можно сделать:
• расклеивая постеры с моделями архитектуры во всей организации;