Е. Всяких - Практика и проблематика моделирования бизнес-процессов

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

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

Gartner выделяет следующие временные горизонты для реализации и использования архитектуры предприятия, которые могут быть применены к модели бизнес-архитектуры, являющиеся ее составной компонентой:

♦тактическое окно – 9 месяцев;

♦скользящее окно оперативных возможностей – 18 месяцев;

♦стратегическое окно – 30 месяцев.

Архитектура должна приносить пользу прежде всего с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно перемещаться и соответствовать интервалу примерно в 18 месяцев. Это тот период времени, который связан с понятием «архитектура завтрашнего дня». Стратегическое окно должно быть не более 30 месяцев и соответствовать принятому в компании горизонту стратегического планирования [4] (рис. 8).

Управление процессом создания модели бизнес-архитектуры должно осуществляться в рамках ряда общих руководящих принципов:

♦архитектура бизнес-процессов для состояния «как должно быть» должна проходить обязательные экспертные и расчетные процедуры контроля на эффективность;

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

♦набор моделей бизнес-архитектуры будет поддерживаться в актуальном состоянии, с обеспечением и контролем целостности и взаимосвязи между компонентами;

♦будут разработаны и поддерживаться стандарты и правила (политики) построения бизнес-моделей. В частности, должно быть разработано соглашение о моделировании. Соответствие стандартам и правилам будет контролироваться. Бизнес-архитектура будет неотъемлемой частью всего процесса управления развитием предприятия;

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

♦публикации и распространение информации и документов описания бизнес-архитектуры.

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

С организационной точки зрения работа над проектом по построению модели бизнес-архитектуры ведется на трех основных уровнях:

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

♦уровне внесения существенных изменений в бизнес-архитектуру;

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

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

♦общих принципов, определенных для регионального уровня;

♦специфики деятельности подразделения.

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

Применительно к такой организации проекта должны формироваться соответствующие группы управления, сопровождения и реализации со стороны заказчика и исполнителя. Обычно выделение отдельных структур со стороны заказчика считается целесообразным в случае наличия у него достаточно больших по размеру ИТ-служб, превышающих 100 и более сотрудников. Даже для больших организаций рекомендуется ограничивать состав основной команды 7–8 сотрудниками, а для более детальной проработки компонент бизнес-архитектуры – формировать отдельные проектные группы.

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