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

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

Глава 14 Этап архитектуры процессов Архитектура процессов – это связь между этапом стратегии организации и этапом стартовой площадки (рис. 14.1). Выполнение этапа архитектуры процессов – непременное предварительное условие для любой организации, намеревающейся начать

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

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

Риски этапа архитектуры процессов В табл. 14.1 приведены самые распространенные риски разработки архитектуры процессов.Таблица 14.1. Риски этапа архитектуры процессов и стратегии их снижения Типовой образец этапа архитектуры процессов приведен в Приложении

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

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

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

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

Образец типовой архитектуры Обобщенные целевые показатели: в следующие три года обеспечить рост выручки от реализации на 200 %; обеспечить рост прибыли на 150 % в следующие три года.Общие принципы: наши корпоративные ценности: лучшая ценность за уплаченную

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

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

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

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

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

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

телекоммуникационной компании

А.Р. Диязитдинова ,

доц. каф. ЭИС, к.т.н., доц. dijazitdinova @ mail . ru ,

Е.А. Матвеева,

проф. каф. ЭИС, к.т.н., доц. helen _ matveev а @ mail . ru ,

О.Н. Ольховая,

доц. каф. ЭИС, к.э.н ., olkhovaya @ inbox . ru ,

ПГУТИ, г. Самара

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

The article describes a place of enterprise architecture supporting system in a company management cycle. An algorithm of operating this system is provided, and an interconnection of its main components is described.

Введение

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

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

Телекоммуникационные компании имеют ряд особенностей [

\\* MERGEFORMAT "">6 ], обуславливающих объективную необходимость развития и концепции поддержки архитектуры предприятия:

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

- высокая технологичность и зависимость от сетевой и ИТ-инфрастуктуры .

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

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

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

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

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

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

В литературе широко освещены следующие методологии построения АП: модель Захмана , метод EAP (Enterprise Architecture Planning ) С. Спивака ,TOGAF, методика META Group , методология Gartner , FEAF; DoDAF и т.д. Специфика отрасли связиобусловила развитие концепции NGOSS, которую можно рассматривать как референтную модель архитектуры телекоммуникационной компании. Несмотря на наличие значительного числа методик по созданию АП, ни одна из них не имеет доминирующего положения на рынке.

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

2. Концепция системы поддержки архитектуры предприятия

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

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

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

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

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

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

Обобщенный алгоритм представлен на рисунке.

3. Оценка эффективности бизнес-процессов

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

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

рис.Обобщенный алгоритм работы системы поддержки архитектуры предприятия

Авторамипредлагаетсяввестиряд дополнительных специфическихпоказателей,отражающих особенности деятельности телекоммуникационной компании. В качестве таких показателейестественнорассмотреть (1)зонупокрытия (км² / %); (2)охват населения (чел. / %); (3) общую мощность передатчиков (Вт, кВт); (4) скорость передачи (мощность) радиорелейных линий (РРЛ) (Мбит/с); (5)количество ретранслируемых каналов; (6)времявещанияканалов (час); (7)количествоивысотумачтибашен, предназначенныхдляразмещенияпередатчиков (шт.,метров); (8)количество передатчиков,спутниковыхприемников; (9)протяженностьРРЛ; (10)количествочасовпростояпередатчиков (час).

Положительнуютенденциюразвитиякомпаниибудетхарактеризовать увеличение значений показателей (1) – (7) и уменьшение показателей (8) – (10).

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

Заключение

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

Литература

1. Архитектура предприятия: основные определения [Электронный ресурс] / Данилин А.В., Слюсаренко А.И. / – Интернет-университет информационных технологий. – Режим доступа: http://citforum.ru/consulting/articles/enterprise_arch/2.shtml.-Загл . с экрана.

2. Калянов Г.Н. Управление развитием информационных систем [Электронный ресурс] / Васильев Р.Б., Калянов Г.Н., Левочкина Г.А. – Интернет-университет информационных технологий. – Режим доступа: http://www.intuit.ru/department/itmngt/mandevisys. - Загл . с экрана.

3. Краснов С.В., Диязитдинова А.Р. Концепция системы поддержки архитектуры предприятия [Текст] // Вестник Волжского университета им. В.Н. Татищева №2 (19) 2012, с. 60 – 65.

4. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными копаниями / К.Е. Самуйлов , А.В. Чукарин , Н.В.Яркина . – М.: Альпина Паблишерз , 2009. – 442 с.

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

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

Следующей ступенью развития ИТ-архитектуры явилось понятие корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture ). На этом этапе ИТ-архитектура включала в себя помимо технологического уровня описания архитектуры информации и архитектуры прикладных систем. Основное направление работ в этом случае состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем. Обобщенная ИТ - архитектура должна включать в себя как логические, так и технические компоненты. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Техническая архитектура определяет конкретные стандарты и правила, которые будут использоваться для реализации логической архитектуры.

Такой подход обеспечивает более эффективное взаимодействие структурных подразделений организации 8:

· совместный доступ к информации различных подразделений, а также внешних организаций (клиентов, партнеров, поставщиков);

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

· решение проблемы интеграции и взаимодействия информационных систем.

· Традиционно ИТ - архитектуру предприятия представляют в виде трех взаимосвязанных компонентов:

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

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

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

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

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

Информационная архитектура (EIA - Enterprise Information Architecture) или архитектура информации – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий в себя:

· базы данных и хранилища данных;

· информационные потоки (как внутри организации, так и связи с внешним миром).

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

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

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

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

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

· идентификация существующих данных, определение их источников и процедур использования;

· оптимизация данных за счет сокращения дублирования, исключение неоднозначности и противоречивости информации;

· минимизация перемещения данных за счет их оптимального расположения;

· интеграция метаданных для обеспечения их целостного представления;

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

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

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

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

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

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

Рис. 1.18. Информационная архитектура

Архитектура прикладных решений (ESA - Enterprise Solution Architecture) или архитектура приложений состоит из совокупности программных продуктов и интерфейсов между ними.

В архитектуре прикладных решений выделают два направления:

· разработка прикладных систем;

· использование прикладных систем.

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

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

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

· интерфейсы – описывают взаимодействие приложений с внешними объектами (программными продуктами, пользователями).

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

Приложение имеет определенный набор функций (Application function), обеспечивающих поддержку ИТ-сервисов (IT service) и бизнес-процессов (Business process).

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

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

Рис. 1.19. Связи информационной системы

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

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

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

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

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

· аналитические приложения, бизнес-аналитика, поддержка принятия управленческих решений (Analytical and Business Intelligence ) – то есть все ИС, связанные с управлением знаниями, обеспечивающие сбор и анализ больших массивов данных в короткие промежутки времени;

· приложения для осуществления совместной работы (Collaborative ) - включает различные средства взаимодействия пользователей внутри компаниями;

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

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

Таблица 1.2 - Характеристики основных типов прикладных систем

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

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

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

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

Оценка портфеля информационных систем (Application portfolio assessment ) – используется для идентификации проблемных областей и возможностей удовлетворения потребностей бизнеса и состоит из следующих разделов:

· вывод приложений из эксплуатации, замена (phase out / replace);

· переоценка необходимости приложений (re-evaluate / reposition);

· разработка новой инфраструктуры ИС (application infrastructure development);

· обеспечение сопровождения и развития ИС (maintain / evolve).

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

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

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

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

3) Большое количество сотрудников (свыше 500) не может выполнять свои непосредственные обязанности. Подобная ситуация может привести к совершенно неожиданным потерям для предприятия.

В соответствии с представленными выше критериями все ИС на предприятии можно разделить на следующие уровни критичности:

Level 1. Mission-Critical . Системы непрерывного действия для решения особо важных (критичных) задач. Сбой систем подобного уровня выводит из строя, парализует работу всего комплекса информационных систем или оказывает существенное влияние на функционирование компании.

Показатель функционирования ИС уровня Mission-Critical – сбой ИС парализует работу компании (например, компания не может предоставлять основные услуги Абоненту).

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

Показатели функционирования ИС уровня Business-Critical:

· сбой ИС приводит к существенным финансовым потерям;

· сбой ИС может привести к сбою работы систем Mission-Critical;

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

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

Показатели функционирования ИС уровня Business Operational:

· сбой ИС приводит к финансовым потерям;

· сбой ИС, возможно, приводит к сбою работы систем Business-Critical.

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

Алгоритм определения уровня критичности систем:

1) Определение перечня основных бизнес-процессов предприятия, остановка функционирования которых парализует работу компании или ведет к существенным финансовым потерям.

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

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

4) Оценка экономического ущерба, связанного с остановкой ИС и вероятность его возникновения.

5) Оценка уровня критичности ИС для функционирования предприятия на основании информации собранной на предыдущих шагах.

1.2.5. Техническая архитектура ИС предприятия (ETA)

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

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

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

· сервисы данных : системы управления базами данных, хранилища данных, системы поддержки принятия решений (Business Intelligence);

· прикладные сервисы : языки программирования, средства разработки приложений, системы коллективной работы;

· программное обеспечение ;

· вычислительная инфраструктура : операционные системы и аппаратные средства;

· сетевые сервисы, локальные сети : сетевое аппаратное обеспечение.

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

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

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

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

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

· обеспечение реализации процесса;

· контроль качества процесса.

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

Вопросы для самоконтроля к теме 1

1) Охарактеризуйте содержательную часть информационного менеджмента.

2) В чем заключаются основные цель и задачи информационного менеджмента?

3) Что представляет собой информация как фактор производства и как основа процесса принятия управленческого решения?

4) Что принято относить к информационным технологиям?

5) Назовите, какие Вы знаете технологии построения корпоративной информационной сети?

6) Для каких целей в крупных организациях используют хранилища данных?

7) Что такое OLAP-технологии и для чего их используют?

8) В чем проявляется связь между информационными системами и информационными технологиями?

9) Назовите основные требования, предъявляемые к информационной системе организации.

10) Что понимают под термином «метамодель» организации, как она формируется?

11) Охарактеризуйте взаимосвязь архитектур бизнеса и его информационной системы.

12) На чем основано управление ИТ-портфелем предприятия?

13) Какие уровни абстракции архитектуры предприятия Вы знаете?

14) В чем проявляется стратегическое соответствие бизнеса и информационной системы предприятия?

15) Какова взаимосвязь стратегии и архитектуры информационных технологий предприятия?

16) Как формируется бизнес-архитектура предприятия?

17) Какие уровни критичности информационной системы предприятия существуют и как они определяются?

18) Что понимают под технической архитектурой информационной системы предприятия?