Контрольная работа по «Архитектура предприятия»

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

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

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

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

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

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

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

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

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

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

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

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

Реализация минималистского подхода  и подхода по «достаточно хорошей  архитектуре» осуществляется в соответствии со следующими ключевыми принципами:

¦ быть гибким и разграничивать уровни бизнес-архитектуры. Гибкость может, в  частности, достигаться за счет разделения бизнес-архитектуры на составные  компоненты: организационная, технологическая, информационная и т. д. Это позволяет «локализовывать» необходимые изменения в рамках соответствующих предметных областей, учитывать связь (влияние) изменений между предметными областями и таким образом исключать необходимость переделки всей архитектуры целиком;

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

Ключевым условием, определяющим эффективное  распределение ресурсов для исполнения проекта по моделированию бизнес-архитектуры, является обеспечение соответствия планирования проекта базовым рекомендациям. А именно построение модели бизнес-архитектуры  должно охватывать три временных  окна: состояние «как есть», состояние  «как должно быть» на ближайшую перспективу  и состояние «как должно быть»  на отдаленную перспективу. Gartner рекомендует  распределение ресурсов между данными  промежутками устанавливать 15 %, 70 %, 15 % соответственно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В табл. 7 приведены характерные качества, которыми должны в идеале обладать члены команды по формированию модели бизнес-архитектуры [4].

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