Андрей Коптелов, Проблемы теории и практики управления, январь 2010
В последнее время внешняя среда изменяется весьма быстро, поэтому требования к адаптивности предприятий возрастают год от года. Различные аналитические исследования показали, что большинство международных компаний не успевают адаптироваться к происходящим изменениям, при этом тренд в этой области является отрицательным. Основная проблема в обеспечении адаптивности предприятий – это согласование и контроль изменений, которые необходимо провести в его рамках. При изменении целей меняется стратегия, что в свою очередь приводит к изменению бизнес-процессов и приоритетов проектов, а также организационной структуры. Все это косвенным образом влияет на уровень знаний и полномочий на предприятии и, как следствие, на информационные потоки, что в свою очередь потребует изменений в существующих информационных системах.
Архитектура предприятия
Чтобы решить указанную проблему необходимо проанализировать все элементы предприятия. Такая совокупность элементов называется архитектурой предприятия. Управление архитектурой предприятия (Enterprise Architecture) создает основу для синхронизации объектов внутри предприятия и в то же время обеспечивает их непрерывное изменение для целей оптимизации бизнеса. Контроль изменений и согласованность всех элементов архитектуры способствуют повышению адаптивности предприятия, что в настоящее время является важным фактором в конкурентной борьбе. При этом фактором, сдерживающим изменения, часто могут стать информационные системы, а значит, особое внимание следует уделять синхронизации элементов бизнес-архитектуры и ИТ-архитектуры. Для управления архитектурой предприятия используется стандартный цикл, состоящий из следующих шагов: описание существующей архитектуры, проектирование ее целевого состояния, формирование плана перехода от существующей к целевой архитектуре. На первом шаге необходимо определить, какие элементы архитектуры и в каком объеме нужно описывать.
С одной стороны, детальность создаваемого описания означает более глубокую проработку, а с другой – появляются излишние трудозатраты как на создание самого описания, так и на поддержку его в актуальном состоянии. Как говорится, «лучшее враг хорошего», и поэтому слишком подробное описание элементов архитектуры не приносит пользы. На этом этапе важно установить ключевые элементы архитектуры предприятия из всех возможных и сосредоточиться именно на их описании и анализе. Практика показывает, что первое рассогласование в архитектуре предприятия, как правило, возникает между целями, бизнес-процессами и организационной структурой. Во многих случаях множество целей не поддержаны необходимыми ресурсами и бизнес-процессами. Следовательно, уже в процессе анализа архитектуры можно определить план работ по оптимизации деятельности предприятия в этой области. Если проанализировать информационные технологии предприятия, то они также часто бывают несогласованными с его существующими, а тем более целевыми бизнес-процессами. Здесь тоже появляется обширное поле для оптимизации деятельности.
Помимо несогласованности между ключевыми элементами архитектуры предприятия часто возникают проблемы и внутри отдельного элемента, в первую очередь это дублирование, а также организационные и информационные разрывы и т.д. Однако не только числом изменений и требованием к адаптивности предприятия вызвано такое серьезное внимание к вопросам управления архитектурой. Сложность технологических систем возрастает, что означает снижение их надежности. В этом случае формализация архитектуры становится базой для обеспечения процедур управления операционными рисками и на предприятии, поскольку если ее основные элементы формализованы, то определить риски и проанализировать эффективность процедур контроля уже не представляет особой сложности. Следовательно, наиболее критично управление архитектурой в крупных компаниях, использующих сложные технологии, которые сопряжены с множеством операционных и технологических рисков.
Управление архитектурой предприятия
Сегодня российские предприятия начали использовать архитектурный подход при совершенствовании своей деятельности и при внедрении ИТ-приложений, хотя нам еще далеко до таких лидеров в этой области как США. Архитектура предприятия должна стать основой для определения его структуры (цели, ключевые показатели результативности, бизнес-процессы, организационная структура и т.д.), информации, необходимой для ведения бизнеса (данные, документы и т.д.), и информационных технологий, используемых для поддержки бизнес-процессов. Фактически можно выделить бизнес-архитектуру и ИТ-архитектуру предприятия. Согласованность всех элементов архитектуры между собой позволит улучшить деятельность предприятия, при этом для быстрой адаптации необходимо управлять изменениями в целях обеспечения соответствия существующей архитектуры изменяющейся внешней среде. Для решения задач построения архитектуры предприятия создано множество методологий:
-
модель Захмана (Framework for Information Systems Architecture) – методика описания архитектуры информационных систем;
-
DoDAF (Department of Defense Architecture Framework) – методика описания архитектуры Министерства обороны США, ранее известная под названием C4ISRAF;
-
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. В него входит ряд ведущих производителей в области ИТ (рис. 1). При этом нужно отметить, что данная архитектура не является эталонной моделью, а скорее является методологией разработки архитектуры предприятия.
-
Принципы систематизации и документирования
-
Определение стратегии и видения
-
Бизнес архитектура
-
Архитектура ИС: приложения и данные
-
Технологическая архитектура (ИТ-инфраструктура)
-
Возможности и решения
-
План миграции
-
Управление проектом внедрения
-
Управление изменениями
Рис. 1. Архитектура TOGAF От бизнес- архитектуре к архитектуре ИТ
Согласование требований бизнеса и возможностей информационных технологий является одним из ключевых преимуществ при управлении архитектурой предприятия. Сейчас развитие современного бизнеса трудно представить без применения информационных технологий, так как результативность существующих бизнес-процессов зависит от качества их информационной поддержки. Часто на крупных предприятиях каждое подразделение использует в работе «собственные» информационные системы, начиная от электронных таблиц и заканчивая «тяжелыми» ERP-системами. Однако во многих случаях отсутствует единый взгляд на использование информационных систем в рамках «сквозного» процесса предприятия.
При этом если автоматизацией бизнеса заниматься несистемно и без применения архитектурных подходов, то в скором времени оно столкнется с серьезными проблемами, связанными с использованием информационных технологий и их соответствием требованиям бизнеса. В начале развития деятельности предприятия использование различных информационных систем, иногда дублирующих друг друга, кажется не очень серьезной проблемой. Однако по мере увеличения его размера число информационных систем растет и в какой-то момент, при попытке осуществить требуемые изменение в бизнес-процессе, который затрагивает многие подразделения, придется изменять большое число различных ИТ- решений, что потребует значительных ресурсов. К сожалению, эта проблема возникает от пренебрежения архитектурным подходом при планировании совершенствования информационных технологий. Еще одной проблемой большинства предприятий является отсутствие качественного документирования существующих ИТ-решений.
Внедренные информационные системы должны быть документированы на требуемом уровне, в противном случае предприятие через некоторое время столкнется с «черным ящиком», работа которого непонятна никому. В российской практике существует множество случаев, когда предприятия отказывались от внедренной информационной системы из-за некачественного документирования и начинали внедрение новой системы. Это происходит из-за невозможности вносить изменения в такую систему, что делает ее не удобной для бизнеса. Таким образом, управление архитектурой предприятия позволит решить основную проблему автоматизации бизнес-процессов – сократить «разрыв» между существующими процессами и средствами их автоматизации. В основном причинами такого разрыва являются неформализованность бизнес-процессов и требований к информационной системе, а также сложность внесения изменений в ИТ-решения. Если не предпринимать специальных действий, то этот «разрыв» будет только увеличиваться со временем, пока не произойдет отказ бизнеса от использования информационной системы.
В настоящее время на ИТ-рынке закончилась «ERP-эйфория» – поскольку стало понятно, что не полностью автоматизировать бизнес с использованием одной монолитной информационной системы. Множество предприятий, вложив миллионы долларов в автоматизацию, так и не получили требуемых преимуществ. Теперь понятно, что «зоопарк» информационных систем на предприятии неизбежен, поэтому сегодня необходимо описывать и анализировать существующую ИТ-архитектуру и синхронизировать ее с бизнес- архитектурой, а не надеяться на полномасштабную автоматизацию с помощью одной информационной системы. Сложность взаимодействия бизнес-архитектуры и ИТ-архитектуры усугубляется масштабностью бизнеса в глобальных холдингах, а также наследованием бизнес-процессов и информационных систем в результате слияний и поглощений. При повышении уровня использования информационных технологий растет зависимость бизнеса от качества и надежности поддерживающих его информационных систем и ИТ-инфраструктуры, что в свою очередь требует четкости и прозрачности взаимосвязи бизнес-процессов с ИТ-архитектурой и ИТ-инфраструктурой.
Следовательно, основными требованиями к существующей ИТ-архитектуре и ИТ-инфраструктуре предприятия являются надежность поддержки бизнес-процессов, а также гибкость существующих информационных систем, заключающаяся в способности быстро адаптироваться к изменяющимся бизнес-процессам. Все эти требования можно выполнить, если системно заниматься автоматизацией бизнес-процессов, уделяя внимание вопросам построения как ИТ-архитектуры, так и архитектуры бизнеса в целом, что делает применение архитектурных подходов необходимым для обеспечения выживаемости бизнеса в современных условиях.
Ключевые элементы архитектуры предприятия
Несмотря на разнообразие методологий в области управления архитектурой на практике большинство предприятий ограничиваются ее следующими элементами: цели бизнеса; организационная структура; ключевые показатели результативности; бизнес-процессы; портфель проектов; документы; информационные системы; знания персонала. Это тот необходимый минимум, который позволяет согласовать основные элементы архитектуры между собой. Однако если цели, показатели, организационная структура и бизнес-процессы часто уже как-то взаимосвязаны между собой, то между процессами и информационными системами такой взаимосвязи часто нет. В связи с этим одной из первоочередных задач для многих предприятий является переход от моделей и регламентов бизнес-архитектуры к определению требований к информационным технологиям и построению соответствующей им ИТ-архитектуры.
Информационный разрыв вызван передачей информации от бизнес-аналитиков к ИТ-специалистам, и в этот момент формализация таких элементов архитектуры, как требования, ИТ-функции, транзакции, структура данных вместе с бизнес-процессами позволяет этот разрыв сократить. На данном этапе важно правильно использовать рекомендации, содержащиеся в методологиях описания архитектуры предприятия, например в TOGAF. Таким образом, для устранения «информационного разрыва» необходимо расширять описание существующей архитектуры предприятия и, в частности, архитектуру бизнеса в направлении ИТ-архитектуры с учетом единства используемой методологии описания как для бизнес-аналитиков, так и для ИТ-специалистов. При таком переходе от описания архитектуры бизнес-процессов к описанию ИТ-архитектуры важно формализовать несколько дополнительных элементов архитектуры. В первую очередь нужно описать архитектуру данных, которая строится на основании той информации и документов, которые используются в бизнес-процессах, после чего следует сформировать архитектуру приложений и ИТ- инфраструктуру (рис. 2.).
Рис. 2. Переход от бизнес- архитектуры к ИТ-архитектуре (приложения, информация, инфраструктура)
Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации, собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи следует использовать стандартную методологию описания данных – модель «сущность–связь» (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).
Заключение
Основной задачей при управлении архитектурой предприятия является синхронизация всех ее элементов между собой. Для этого необходимо обеспечить взаимосвязь бизнес-архитектуры и ИТ-архитектуры, с одной стороны, через документирование, совершенствование и стандартизацию бизнес-процессов, а с другой – через описание элементов ИТ-архитектуры на логическом уровне, во взаимосвязи с бизнес-процессами. Следует отметить, что концентрация в управлении архитектурой предприятия должна происходить лишь на ключевых элементах, что позволит получить максимальный результат с минимальными ресурсами. Распыление ресурсов на описание всех элементов архитектуры часто дает отрицательный результат с точки зрения бизнеса, поскольку отодвигает горизонт решения существующих проблем на длительный период. Цели, показатели, процессы, проекты, организационная структура, документы, данные, приложения – вот тот необходимый минимум, который обеспечит внедрение архитектурных подходов в деятельность предприятия. Что касается глубины описания, то в этом случае, если есть возможность обойтись существующим уровнем описания – нет смысла создавать еще один. Такой подход позволит сэкономить много ресурсов и получить значимый для бизнеса результат. Имея картину существующего положения и разработав модель целевой ИТ-архитектуры, можно создать программу унификации и стандартизации ИТ-решений на предприятии, что обеспечит сокращение затрат на информационные технологии в коротком промежутке времени.
ЛИТЕРАТУРА ·
Архитектура и стратегия. "Инь" и "Янь" информационных технологий предприятия, Данилин А., Слюсаренко А. , ИНТУИТ, 2005 ·
Сервисно-ориентированная архитектура: «за» и «против», Коптелов А.К. Журнал Intelligent enterprise 24 октября, 2007 г. № 16 (172) ·
Управление IT-архитектурой или как сократить затраты на ИТ, Журнал Генеральный директор. Управление промышленным предприятием, июнь, 2009 г. № 6
|
Главная 
