Проблемы управления предприятием архитектура бизнеса

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

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

«Архитектура предприятия устанавливает путь к достижению миссии организации благодаря оптимальному функционированию ее ключевых бизнес-процессов внутри эффективного ИТ- окружения.” Jaab Schekkerman, Institute For Enterprise Architecture Development (IFEAD).

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

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

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

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

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

Управление архитектурой предприятия

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

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

Для решения задач построения архитектуры предприятия создано множество методологий (Frameworks):

• Модель Захмана (Framework for Information Systems Architecture) — методика описания архитектуры информационных систем;

• DoDAF – Department of Defense Architecture Framework – методика описания архитектуры Министерства обороны США, ранее известная под названием C4ISR AF;

• FEAF – Federal Enterprise Architecture Framework — Федеральная Архитектура Государственных организаций США;

• TEAF — Treasury Enterprise Architecture Framework — методика описания архитектуры казначейства США;

• TOGAF – The Open Group Architecture Framework — методика описания архитектуры разработанная Open Group;

• NASCIO — National Association of State Chief Information Officers – методика, разработанная Национальной ассоциацией CIO США;

• NATO Architecture Framework — методика описания архитектуры НАТО;

• Enterprise Architecture Desk Reference — документ компании META Group;

• и т.д.

Информация о новейшей архитектуре от Open Group — IT4IT — Reference Architecture

Самой первой считается модель Захмана, созданная в 1987 году, на ее основе были разработаны многие существующие модели и методики в области управления архитектурой предприятия. Все эти наработки в той или иной степени задают классификацию основных элементов архитектуры и единые принципы для их описания во взаимной увязке друг с другом, а также используемые правила и модели, которые применяются для формализации элементов архитектуры на разных уровнях детализации. В качестве примера одной из методологий можно привести элементы архитектуры TOGAF, которая предложена некоммерческим объединением Open Group, в которое входит ряд ведущих производителей в области. При этом нужно отметить, что данная архитектура не является эталонной моделью, а скорее является методологией разработки архитектуры предприятия.

От бизнес- архитектуре к архитектуре ИТ

Согласование требований бизнеса и возможностей информационных технологий является одним из ключевых преимуществ от управления архитектурой предприятия. Сейчас развитие современного бизнеса трудно представить без применения информационных технологий, ведь результативность существующих бизнес-процессов зависит от качества их информационной поддержки. Часто в крупных компаниях каждое подразделение использует в работе «собственные» информационные системы, начиная от электронных таблиц и заканчивая «тяжелыми» ERP – системами. Однако во многих случаях отсутствует единый взгляд на использование информационных систем в рамках «сквозного» процесса компании.

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

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

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

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

Ключевые элементы архитектуры предприятия

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

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

Переход от бизнес- архитектуры к ИТ — архитектуре (приложения, информация, инфраструктура)

Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи можно использовать стандартную методологию описания данных — модель «сущность-связь» (Entity-Relationship Model – ERM), в рамках которой можно четко структурировать всю информацию.

Следующим этапом формализации ИТ-архитектуры является переход от архитектуры бизнес-процессов и архитектуры данных к созданию архитектуры приложений. На этом этапе необходимо определить классы информационных систем, необходимых для автоматизации, после чего определить необходимые модули для каждой информационной системы. Здесь, основой для проектирования архитектуры приложений и ее синхронизации с бизнес -архитектурой является карта процессов (обобщенное представление всех бизнес-процессов предприятия). На модели архитектуры приложений располагаются основные типы информационных систем, которые далее детализируются на модели модулей информационных систем, и далее до уровня отдельных экранных форм — транзакций. Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнеса и ИТ являются требования к информационной системе.

Фактически модели требований — это целевой функционал ИТ — решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 году TeleManagement Forum, и содержит следующие модели: ·

• информационная модель телекоммуникационного предприятия (Enterprise-wide information framework Shared Information and Data Model — SID);

• структура приложений телекоммуникационной компании (Applications framework – Telecom Applications Map — TAM).

Заключение

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

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

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

Время на прочтение
6 мин

Количество просмотров 2.8K

Бизнес-архитектура и ее место в компании

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

Таким образом, архитектура в городе — это наука не только о строительстве и проектировании, но еще и о структурировании.

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

Согласно методологии TOGAF, через бизнес‑архитектуру происходит постановка бизнес‑целей и управление ИТ‑архитектурой. Она связывает стратегию и тактику, помогает лучше понять потребности в целом.

Структурирование разрозненной бизнес‑информации, связь ее элементов в целостные группы необходимы для формирования бизнес‑ландшафта. Чем понятнее бизнес‑ландшафт, тем удобнее управлять им и, как следствие, компанией.

Управление бизнес‑архитектурой — это процесс, которым нужно заниматься: своевременно обновлять данные, обрабатывать и анализировать их. Из этих же данных, например, обычно формируется бизнес‑стратегия.

Взгляд со стороны ИТ

Зачем вообще разрабатывать единую архитектуру для работы компании? Рассмотрим этот вопрос с точки зрения Блока информационных технологий Страхового Дома ВСК.

• Во‑первых, часто бывают случаи, когда Заказчик и Исполнитель смотрят по‑разному на одну и ту же автоматизацию. Поэтому единый взгляд очень важен, как и единое мерило (которое имеет однозначное трактование «да» или «нет).

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

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

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

Основные бизнес-составляющие

Так случилось, что в один момент ИТ‑архитектура нашей компании устарела и перестала отвечать на вызовы рынка. Развитие ее стало долгим, дорогим и мучительным. Появилась явная цель — избавиться от старых приложений (legacy out) и реализовать новые.

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

Сервисы

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

Если бизнес‑процесс — это графическое описание последовательности шагов, выполняемых сотрудниками по одной или нескольким бизнес‑функциям, а его цель — повышение эффективности процессов компании; то сервис — это услуга, предоставляемая клиенту и имеющая для него ценность. Основная цель сервиса — повышение клиентоориентированности.

В методологии Agile, во фреймворке SAFe, есть понятие «Value stream». Это картирование — сбор и анализ информации о процессах в потоке, оптимизация операций с точки зрения ценности действий и целесообразности затрат. Ценность рассматривается с точки зрения клиента.

Можно сказать, что наши сервисы — это маленькие велью стримы. Они нарезаны вокруг услуги, продукта, канала продаж и взаимодействий.

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

Способности

Способность (Capability) — это умение (или навык) компании. Мы только начинаем работу в этом направлении. На данный момент совместно с Ассоциацией ФинТех (далее — АФТ) разработан драфт функциональной карты страхового рынка. На ее основании реализован каталог способностей до 3 уровня.

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

Дашборды

Речь идет о визуализации показателей в информационном разрезе компании. Дашборды представляют собой матрицу, имеют цветовую идентификацию и возможность Drill Down.

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

Архитектура решения

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

Фронт работ над ПО: развитие функционала по первичному учет сервисов, интеграция с Jira, автоматическое обновление дашбордов, формирование требований и разработка функционала по работе со способностями.

Касательно сервисов, важно отметить следующие пункты:

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

• для каждой задачи в Jira необходимо указать сервис и/или способность;

• дашборды должны стать инструментом визуализации для планирования и развития.

  

Перспективы развития

В 2022 году мы определили целевую концепцию и разработали базовый функционал по сервисам. Далее рассматриваем следующий план взаимодействия с Бизнесом:

• ИТ дорабатывает инструмент, осуществляет первичное наполнение данными и использует дашборды для общения с Бизнесом об уровне и качестве автоматизации;

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

Стратегия развития бизнес‑архитектуры следующая:

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

• автоматизация сбора информации: автоматизация сбора данных об уровне и качестве автоматизации на основании сервисов, сбор статистики по сервисам → автоматизация ручного ввода;

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

* Цифровой двойник — это виртуальная модель любых объектов, систем, процессов или людей, которая состоит из физического продукта в реальном пространстве, цифрового продукта в виртуальном пространстве, данных и информации, которые объединяют цифровой и физический продукты.

Заключение

Выше описан взгляд Страхового Дома ВСК на организацию бизнес‑архитектуры и практический подход к реализации.

Сейчас появляется все больше активностей, которые активно развиваются и создают поводы для обсуждения: в рамках импортозамещения ЦБ формирует функционально технологическую карту, а АФТ интересно развитие функциональной карты для страхового рынка как некого мерила и светофора его автоматизации.

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

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

Если у Вас есть интерес — пишите skirillov@vsk.ru

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

Собственно, в этой статье вы узнаете зачем нужна бизнес-архитектура предприятия и сможете ответить на вопрос: нужна ли она именно вам?

Комплексное понимание стратегии и устройства компании

Результаты многочисленных исследований неутешительны – менее, а порой значительно менее, 50% сотрудников понимают стратегию компании. Да, сотрудники понимают свою деятельность, но далеко не всегда осознают свое место в бизнес-системе. Говоря иначе, сотрудники не знают, как устроена вся деятельность организации. Вследствие этого они, сотрудники, не понимают, как применить свои навыки и ресурсы, чтобы получить оптимальную ценность для организации.

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

Согласованность людей, процессов, ресурсов, технологий, возможностей и стратегии

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

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

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

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

Создание единой системы показателей эффективности

В большинстве компаний система показателей эффективности отсутствует. Да, есть отдельные показатели или их наборы. Но системы показателей, основанной на взаимосвязи элементов бизнеса, нет.

Создание системы показателей эффективности – непростая задача. Как раз в силу сложности взаимосвязей сущностей, с которыми связаны показатели.

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

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

Система показателей эффективности, как и бизнес-архитектура – инструмент управления. 

Формирование ценности в соответствии с потребностями заинтересованных сторон

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

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

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

Согласованность потребностей бизнеса и возможностей ИТ

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

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

Проще говоря, через бизнес-архитектуру предприятия осуществляется полноценное встраивание ИТ в деятельность компании. А именно это чаще всего и не хватает. Не «бизнес и ИТ», а «ИТ как часть бизнеса». Что называется, почувствуйте разницу.

Вывод процесса планирования на новый качественный уровень

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

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

С точки зрения планирования бизнес-архитектура позволяет избежать:

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

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

Приоритезация и обеспечение финансирования инициатив

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

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

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

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

Увеличение вовлеченности персонала и эффективности взаимодействия

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

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

Правильная бизнес-архитектура позволяет обеспечить вовлеченность двумя способами:

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

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

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

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

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

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

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

• Классическая или, другими словами,
  эталонная архитектура предприятия
  является идеальной моделью построения
  организации.

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

• Специфическая архитектура — так обычно
  называют исторически сложившуюся
  на данном предприятии модель бизнес —
  процессов.

Построение бизнес — архитектуры начинается
с описания контекста бизнес — архитектуры
(рисунок 1.8.).

Общее видение бизнес — архитектуры
предприятия включает анализ основных
функций, цепочек создания добавленной
стоимости (ValueLandscapeAnalysis), модели бизнес –
сценариев (BusinessScenarioModels), анализ информационных
связей и процессов (InformationValueChainAnalysis).

Рисунок 1.8.
Контекст бизнес архитектуры

Основу архитектуры предприятия
составляет: анализ бизнес событий
(BusinessEventAnalysis), декомпозиция функций
и процессов (Function/ProcessDecomposition), модель расположения
(LocationModel),
модель интеграции (IntegrationModel).

Бизнес — архитектура представляется в
виде набора бизнес моделей. Бизнес
модели – это «набор событий, связанных
с бизнесом, в который вовлечены различные
функции бизнеса, организационные единицы
и активы предприятия».

В настоящее время существуют различные
методики описания бизнес — архитектуры
предприятия. Например, в работах Джона
Захмана выделяются следующие типы
бизнес моделей:

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

• Динамические модели бизнес-процессов,
  включающие детализированное описание
  функционирования компании.

• Организационная структура компании.

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

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

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

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

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

• выделить ключевые бизнес-процессы;

• выделить дублирующие бизнес-процессы
  и точки их пересечения.

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

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

Модель интеграцииопределяет связь
бизнес-процессов и бизнес — событий.

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

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

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

4. ИТ — архитектура
предприятия

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

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

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

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

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

• Enterprise Information Architecture (EIA) –
  информационная архитектура.

• Enterprise Solution Architecture (ESA) –
  архитектура прикладных
  решений.

• Enterprise Technical Architecture (ETA) –
  техническая архитектура.

В ходе разработки архитектуры предприятия
создается модель, включающая информацию
о его производственных процессах,
информационных и материальных потоках,
ресурсах и организационных единицах.
При этом модель ИТ — архитектуры
непосредственно зависит от роли, которую
выполняют информационные системы на
предприятии: стратегическая (ориентированная
на выполнение сложившихся стратегий и
операций), сдвигающая (инструмент для
увеличения эффективности бизнеса),
поддерживающая (ИС не играют особой
роли в функционировании предприятия),
заводская (ИС являются обязательным
элементом, обеспечивающим функционирование
бизнеса). Модель предприятия (соответствующая
ее роли) позволяет не только давать
лучшее представление о структуре
предприятия, но и является эффективным
инструментом для анализа экономических,
организационных и многих других аспектов
его функционирования.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

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

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

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

Что такое архитектура предприятия?

Под архитектурой предприятия (Enterprise Architecture, EA) обычно понимается полное описание (модель) структуры предприятия как системы, включающее описание ключевых элементов этой системы, связей между ними. Аналитики IBM считают, что «дисциплина Enterprise Architecture определяет и обслуживает архитектурные модели, механизмы управления и инициативы по переходу (от текущего состояния к целевому), необходимые для эффективной координации частично автономных групп при решении бизнес- и (или) ИТ-задач».

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

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

Один из традиционных вопросов, возникающих при разработке архитектуры предприятия, — о необходимости ее внедрения. Большинство топ-менеджеров предпочитают давать обоснование инвестиций в архитектуру предприятия в виде ROI, но, по мнению аналитиков компании Gartner, ни одно из этих обоснований не являлось правдоподобным. «За десять лет работы с тысячами компаний Gartner не видела ни одного примера надежного обоснования ROI для программы создания EA, — говорит Брайан Бурк, один из ведущих аналитиков Gartner в области построения архитектуры предприятия. — Вывод: этого нельзя сделать — и не начинайте».

Оценка эффективности архитектуры предприятия является одним из важных факторов архитектурного процесса. Но в основу его правильнее закладывать качественные, а не количественные методики оценки.

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

• Как архитектура предприятия влияет на ИТ?
• Как архитектура предприятия непосредственно влияет на бизнес?

Архитектура предприятия: от теории к практике

В различных архитектурных методиках все выглядит очень просто и красиво. Необходимо выбрать одну из понравившихся методологий (TOGAF, Zachman Framework, Gartner Enterprise Architecture Framework, Oracle Enterprise Architecture Framework), на ее основе разработать свой вариант архитектуры, внедрить архитектурный процесс и начать рисовать модели средствами одного из понравившихся архитектурных инструментов. Это в теории.

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

Аналитики Gartner выделили четыре группы процессов, которые выполняются различными командами специалистов.

Тактическая архитектура (Tactical Architecture) — включает в себя архитектуру локальных проектов, выполняющихся в соответствии с конкретным планом развития информационных систем и бизнес-процессов. Специалисты, занимающиеся такими проектами, как правило, являются профессионалами в конкретных областях, они занимаются главным образом решением текущих задач и часто не могут оценить их влияние на предприятие в целом.

Тактическая архитектура предприятия (Enterprise Tactical Architecture) — координирует все проекты предприятия, обеспечивает интеграцию различных приложений в единое целое. Аналитики, работающие в такой команде, имеют широкое представление о существующих проблемах, могут влиять на выбор того или иного решения. При этом разработка архитектуры происходит только с точки зрения технологий и не затрагивает бизнес.

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

Зрелая архитектура предприятия (Mature Enterprise Architecture) — должна объединять всю основную активность, направленную на разработку архитектуры предприятия, в единое целое, планируя и определяя будущую архитектуру предприятия. Архитектурная команда становится неотъемлемой частью бизнеса, планирует управление финансовой деятельностью и действия по управлению портфелем приложений, консультирует другие рабочие группы по вопросам дальнейшего технологического развития и бизнес-стратегии.

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

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

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

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

Архитектура предприятия влияет на все этапы, связанные с разработкой решения, и включает в себя четыре основных направления.

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

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

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

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

Архитектура предприятия и ITIL

В настоящее время наиболее популярный способ документирования состояния информационных систем и ИТ-инфраструктуры — это внедрение процесса управления конфигурациями (Configuration Management). Процесс ориентирован в первую очередь на хранение данных по объектам ИТ-инфраструктуры в форме конфигурационных единиц и связей между ними, но его часто используют для хранения любой документации по существующим приложениям.

В ITIL версии 3 появляется система управления знаниями по услугам (Service Knowledge Management System, SKMS) с которой взаимодействуют процессы управления ИТ. Система SKMS может хранить в себе не только стандартную информацию о конфигурационных единицах, но и «заявки на предоставление доступа к услугам, инциденты, проблемы, ошибки, изменения, релизы».

Пользователь CMDB (Configuration Management Data Base) нуждается в интеграции ИТ-сервисов и их компонентов для оптимизации оперативных изменений. Цель процесса управления конфигурациями — оптимизировать работу ИТ для бизнеса.

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

Сейчас появился отдельной класс инструментов, обеспечивающих не только моделирование архитектуры предприятия, но и автоматизацию архитектурного процесса (Enterprise Architecture Management). Архитектурные инструменты имеют собственный репозиторий, где хранится необходимая информация. Эту информацию, как правило, делят на четыре основные группы:

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

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

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

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

Алексей Сизов — эксперт по системной архитектуре компании «Вымпелком»; alexey.sizov@gmail.com