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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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