Число изменений во внешней среде нарастает с высокой скоростью, и поэтому требования к адаптивности компаний повышаются год от года. В статье рассматриваются основные принципы управления архитектурой предприятия, наиболее известные методы в данной области и преимущества их применения.
Изменения и адаптивность компании
Число изменений во внешней среде нарастает с безумной скоростью, и поэтому требования к адаптивности компаний возрастают год от года. По различным аналитическим исследованиям топ-менеджеры большинства международных компаний больше всего напуганы тем фактом, что их компании не успевают адаптироваться к происходящим изменениям, при этом тренд в этой области отрицательный Во многих случаях основная проблема в обеспечении адаптивности компании – это согласование и контроль требуемых изменений в рамках всей организации. При изменении целей, меняется стратегия, что в свою очередь требует изменений в бизнес-процессах и приоритетах проектов, а также в организационной структуре.
Все это косвенным образом влияет на знания и полномочия внутри компании, а это в свою очередь может привести к изменениям в информационных потоках, которые в свою очередь потребуют изменений в существующих информационных системах. В качестве решения вышеозначенной проблемы, необходимо анализировать все элементы предприятия в целом, при этом такая совокупность элементов называется архитектурой предприятия. Управление архитектурой предприятия (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, и содержит следующие модели: ·
-
модель операций телекоммуникационной компании eTOM (Enhanced Telecom Operations Map – eTOM);
-
информационная модель телекоммуникационного предприятия (Enterprise-wide information framework Shared Information and Data Model – SID);
-
структура приложений телекоммуникационной компании (Applications framework – Telecom Applications Map – TAM).
Заключение
В заключение можно отметить, что основной задачей при управлении архитектурой предприятия является синхронизация всех элементов архитектуры между собой. При этом одной из ключевых задач является взаимосвязь бизнес- архитектуры и архитектуры ИТ с одной стороны через документирование, совершенствование и стандартизацию бизнес-процессов, а с другой через описание элементов ИТ- архитектуры на логическом уровне, во взаимосвязи с бизнес-процессами. При этом концентрация в управлении архитектурой предприятия должна происходить лишь на ключевых элементах, что позволит получить максимальный результат с минимальными ресурсами.
Распыление ресурсов на описание всех элементов архитектуры часто дает отрицательный результат с точки зрения бизнеса, поскольку отодвигает горизонт решения существующих проблем на очень длительный период. Цели, показатели, процессы, проекты, организационная структура, документы, данные, приложения – вот тот необходимый минимум, который позволит начать внедрение архитектурных подходов в деятельность компании. В части глубины описания рекомендация может быть одна – если есть возможность обойтись существующим уровнем описания – нет смысла создавать еще один.
Такой подход позволит сэкономить много ресурсов, при этом получив значимый для бизнеса результат. В части ИТ-архитектуры, имея картину существующего положения и разработав модель целевой ИТ – архитектуры, можно создать программу унификации и стандартизации ИТ- решений в компании, что позволит сократить затраты на ИТ в коротком промежутке времени.
Детальное рассмотрение всех материалов, приведенных в данной статье, можно получить в ученом курсе – Корпоративная архитектура.
Андрей Коптелов, Проблемы теории и практики управления. Выпуск № 01 2010 года