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

Джестон Джон

Шаг 3. Получение нужной информации, принципов и моделей технологий

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

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

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

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

и логики;

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

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

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

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

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

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

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

Шаг 4. Консолидация и сверка

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

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

Схема организационных взаимосвязей

Схема организационных

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

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

Лучший способ выработать такую схему – провести практическое совещание со всеми заинтересованными сторонами, при этом:

• используя цели и стратегию организации в качестве отправной точки;

• внося все разнообразные требования и взгляды заинтересованных сторон;

• выявляя взаимосвязи и противоречия между этими требованиями;

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

• ранжируя требования;

• обсуждая разрывы в процессах и конфликты (включая пути эскалирования на более высокие уровни полномочий);

• подготавливая планы мероприятий для устранения нестыковок и противоречий (включая пути эскалирования);

• предоставляя окончательные выводы соответствующим руководителям, четко обозначив связь со стратегией и целями организации и указывая, как сформулированная архитектура будет содействовать их осуществлению;

• добиваясь окончательного утверждения.

Шаг 5. Обмен информацией

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

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

• обеспечивая применение архитектуры всеми структурными подразделениями при определении объемов и принятии решений;