2. Описание и анализ процессов «как есть». На этом этапе осуществляются описание процессов «как есть» в выбранном средстве моделирования, выбор критериев оценки процессов, выявление и оценка «узких» мест и потенциала для совершенствования. Уточняется план работ по дальнейшим этапам.

3. Построение процессов «как должно быть». На этом этапе определяются и оцениваются альтернативные сценарии процессов, моделируются процессы «как должно быть» с новой организационной структурой и операционным окружением, планируются потребности в персонале и формулируются требования к их квалификации и знаниям. Уточняется план работ по дальнейшим этапам.

4. Подготовка к переходу к оптимизированной модели. На этом этапе разрабатывается план перехода от текущего состояния к целевому:

– создание новых должностных инструкций;

– разработка тренинг-курсов и выработка показателей (метрик) уровня квалификации исполнителей;

– описание временных решений и т. п.

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

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

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

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

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

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

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

а) декомпозиция на различные представления архитектуры (предметные области): организационная, информационная, функциональная, технологическая компонента и т. д.;

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

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

г) мониторинг методической и нормативной базы по оценке бизнес-процессов в организации.

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

Модель бизнес-архитектуры предприятия должна быть скорее гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как «достаточно хорошая» архитектура [15]. При этом принцип «достаточно хорошей» архитектуры противостоит стремлению создания «идеальной» архитектуры. Философия заключается в том, чтобы создать довольно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение [4].

В данных обстоятельствах целесообразно руководствоваться рекомендациями минималистского подхода по проектированию модели бизнес-архитектуры, то есть определять требования к бизнес-архитектуре самого высокого приоритета и затем делать минимально возможное, и не более того, чтобы удовлетворить этим требованиям [16]. Это позволяет иметь ограниченный и контролируемый набор бизнес-моделей высокого уровня (либо ключевых бизнес-процессов), но в то же время оставляет необходимую степень свободы для расширения состава бизнес-процессов, повышения детализации описания как самих бизнес-процессов, так и их компонент.