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

Изменения и адаптивность компании

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

Все это косвенным образом влияет на знания и полномочия внутри компании, а это в свою очередь может привести к изменениям в информационных потоках, которые в свою очередь потребуют изменений в существующих информационных системах. В качестве решения вышеозначенной проблемы, необходимо анализировать все элементы предприятия в целом, при этом такая совокупность элементов называется архитектурой предприятия. Управление архитектурой предприятия (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;

Самой первой считается модель Захмана, созданная в 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).

Заключение

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

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

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

Андрей Коптелов, Проблемы теории и практики управления. Выпуск № 01 2010 года

Рис. 5.2.

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

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

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

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

• Миссия и видение .
• Руководящие принципы . Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий.
• Цели, задачи и стратегии .
• Архитектура информационных технологий .
• Политики (правила) . Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов.
• ИТ-стандарты . Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции.
• Процедуры . Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.
• Руководства или рекомендации (guidelines) . Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

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

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

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

Рис. 5.3.

Важным представляется следующее замечание, сформулированное в архитектурной методике META Group, которое касается роли принципов и моделей в описании архитектуры (более подробно об этом см. в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF"). Можно сказать, что существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия: существенная, возможно, даже большая часть специалистов и компаний считает, что основой архитектуры являются принципы, а другая часть придерживается точки зрения, что основой архитектуры является процесс создания моделей. META Group полагает, что при описании сегодняшней, существующей архитектуры (архитектуры "как есть") необходимо в большей степени руководствоваться декларациями принципов, на основе которой она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

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

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

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

Контекст и основные элементы бизнес-архитектуры

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

По оценке Gartner, вплоть до конца 2005 года около 70% всех предприятий будут вести определенные проекты, связанные с анализом и совершенствованием бизнес-процессов, несмотря на некоторый негативный осадок, который в корпоративном мире имела практика реинжиниринга бизнес-процессов середины 1990-х годов. "На самом деле, большинство предприятий в действительности не понимают всей глубины и масштабов выполняемых ими бизнес-процессов, если они не занимались бизнес-моделированием в последнее время", – считает Джим Синур (Jim Sinur), аналитик Gartner.

Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры приложений, которые обеспечивают эти процессы. Хотелось бы в связи с этим привести следующую цитату из книги Unleashing the Killer App "Вы тогда достигаете цели, когда становится невозможно определить, где заканчиваются бизнес-аспекты, и где начинаются технологии".

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

• Бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации.
• Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы "точкой соприкосновения" между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.
• Показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.

"Если архитектура ИТ предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно также бизнес-архитектура описывает, как элементы бизнеса соединены вместе" .

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

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

Рис. 5.7.

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

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

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

Шаг 1 . Идентификация критически важных для предприятия процессов (обычно не более восьми).

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

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

Желательно, чтобы рекомендуемое число таких процессов, не превышало "волшебного числа" 8 в соответствии с известным принципом: "семь плюс-минус два" объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

Шаг 2 . Отследить связи между этими процессами и бизнес-стратегиями, движущими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу "важно" – "неважно" или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.

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

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

Шаг 5 . Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).

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

системы управления предприятием

Лекция 1. Информационные технологии и архитектура предприятия

1. Понятие архитектуры предприятия

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

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

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

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

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

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

Под архитектурой предприятия (EA - Enterprise Architecture ), обычно понимается полное описание (модель) структуры предприятия, как системы, включающее описание ключевых элементов этой системы, связей между ними.

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

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

Архитектура предприятия описывает деятельность компании с двух основных позиций:

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

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

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

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

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

стратегия и планирование на уровне предприятия;

управление корпоративными проектами.

Рисунок 1.1. Взаимосвязь бизнеса и ИТ

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

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

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

Рисунок 1.2. Управление портфелем ИТ.

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

максимизация ценности портфеля;

синхронизация ИТ - портфеля с требованиями бизнеса;

поиск оптимального баланса между риском и потенциальной отдачей от ИТ - портфеля.

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

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

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

Рисунок 1.3. Контекст и уровни абстракции архитектуры предприятия.

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

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

Уровень отдельных решений – определяет структуру и функции в рамках отдельных проектах. На этом уровне, формируется детализированная информация о приложениях, бизнес-процессах и их взаимосвязях. Здесь определяется структура информационных систем, их интерфейсы и функции. Определяются планы и схемы их развития, разрабатывается соглашение об уровне обслуживания (SLA).

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

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

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

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

Уровень контекста (почему?) ориентирован в первую очередь на руководство и обосновывает необходимость проектов.

Концептуальный уровень (что?) определяет общие требования к проекту и возможные варианты его реализации.

Логический уровень (как?) описывает способ реализации данного проекта.

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

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

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

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

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

Рисунок 1.4. Эволюция организационных принципов.

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

Текущая архитектура (Current architecture) - описывает существующее состояние архитектуры предприятия. Называется также архитектурой “как есть” (AS-IS) или базовым состоянием существующей архитектуры.

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

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

Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM(управление конфигурацией - Configuration Management). Для упрощения работы по разработке текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией.

Целевая архитектура (Target Architecture) - описывает желаемое будущее состояние предприятия или "что должно быть сформировано" (TO-BE). Другими словами, целевая архитектура является будущей моделью предприятия.

Целевую архитектуру можно назвать идеальной моделью предприятия, в основу которой заложены:

стратегические требования к бизнес-процессам и информационным технологиям;

информация о выявленных «узких местах» и путях их устранения;

анализ технологических тенденций и среды бизнес деятельности предприятия.

Целевая архитектура (модель to-be) и текущая архитектура (модельas-is) позволяют описать начальное и конечное состояние предприятия – до и после внесения изменений в его структуру, оставляя без внимания сам процесс изменений.

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

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

Стратегические цели и задачи предприятия.

Бизнес – архитектура предприятия.

Архитектура информационных технологий (ИТ архитектура предприятия).

Архитектуру информационных технологий, в свою очередь, разделяют на:

Информационную архитектуру (Enterprise Information Architecture).

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

Технологическую архитектуру (Enterprise Technical Architecture).

Рисунок 1.5. Основные слои архитектуры предприятия

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

Конфуций

В этой лекции мы обсудим наиболее общие характеристики таких понятий, как " Архитектура информационных технологий" и " Архитектура предприятия".

Прежде чем подойти к описанию того, что такое архитектура ИТ, проще отметить, что ею не является. В частности, архитектурой не является более или менее утвержденный список поставщиков и их продуктов типа "Мы используем серверную ОС MS Windows 2003, СУБД MS SQL , все остальное ПО тоже от Microsoft, серверы на платформе Intel и телекоммуникационное оборудование Cisco". Создание стандартного списка поставщиков и уменьшение их количества – это только частичное решение проблемы "кусочной" информатизации. По мнению Gartner, подход к формулировке архитектуры должен основываться на анализе общекорпоративных процессов и переоценке своих бизнес-процессов и поддерживающих их приложений.

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

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

С другой стороны, представление об архитектуре предприятия имеет свои корни в дисциплине, которая получила название "системное мышление ". Основным объектом изучения этой дисциплины является система, когда "целое составляет нечто большее, чем механическая сумма составляющих, т.е. система обладает свойствами, которые отсутствуют у составляющих ее элементов" . Эберхард Речтин (Eberhardt Rechtin), чья цитата была только что приведена, является одним из основателей этого направления мышления.

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

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

Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В этом плане она дополняет достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL , COBIT и другие.