Баронов В.В., Калянов Г.Н., Попов Ю.Н., Титовский И.Н. Информационные технологии и управление предприятием

Подождите немного. Документ загружается.

121

● направления развития ИТтехнологий у заказчика и стратегий реали

зации (срочные, среднесрочные и перспективные этапы).

ИТархитектура подразделяется на набор областей верхнего уровня (доме

нов), описывающих отдельные аспекты ИТсистемы. В состав списка доменов

входят следующие области:

● управление приложениями;

● управление данными;

● управление информацией;

● управление пользователями и их доступом;

● сети и коммуникации;

● платформы;

● управление системами;

● информационная безопасность и т.п.

Домены, в свою очередь, включают несколько функциональных областей,

например, в домен “Управление системами” входят следующие области:

● управление активами (Asset management);

● управление изменениями (Change management);

● управление событиями (Event management);

● поддержка пользователей (Help Desk);

● обеспечение непрерывности бизнеса (Business continuity) и др.

Для каждой области определяются возможные технологии (например, для

домена “Управление данными” это могут быть реляционные СУБД, почтовые

базы, файловые каталоги и т.п.), продукты и версии продуктов. Для каждой

области, технологии и продукта могут устанавливаться “требования соответ

ствия”, определяющие необходимость соблюдения тех или иных международных

Текущее состояние

23 года

(среднесрочный план)

5 лет

(перспективный план)

Базовая среда

(оценка ASIS)

Тактическое

внедрение

Стратегическое

направление

Снятие

с эксплуатации

Продолжение эксплуатации

Поддержка и сохранение

Развивающиеся

платформы

Следствия

Рис. 7.2. Периоды планирования

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

Глава 7. Архитектура предприятия

122

рекомендаций (RFC), стандартов, российских законодательных актов, напри

мер по применению сертифицированных средств ЭЦП, внутренних инструк

ций и т.п.

Для элементов архитектуры (на уровне домена, функциональной области,

технологии и продукта) в описании архитектуры системы определяется обычно

следующее.

Домен:

● описание, область охвата (какие аспекты ИТсистемы входят/не вхо

дят в данный домен);

● функциональные области, принципы, лучшие практики, тренды.

Функциональная область:

● описание, область охвата, ссылка на домен;

● кроссссылки на другие функциональные области;

● методологии, технологические области;

● требования к документированию.

Технологическая область:

● описание, ссылка на функциональную область;

● обоснование выбора единственного или множественных продуктов (вен

доров, приложений).

Продукт/приложение:

● описание, ссылка на технологическую область;

● информация о вендоре, классификация;

● условия использования, политика миграции.

Важным преимуществом такого подхода является возможность представле

ния всего описания архитектуры в виде гипертекстовой базы данных, что позво

ляет эффективно организовать процессы управления жизненным циклом отдель

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

разделам (например, документам, описывающим применяемые средства защи

ты информации) при сохранении целостности и единства описания.

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

мента определяется реализация применительно к конкретным особенностям

предприятия процессов поддержки жизненного цикла ИТархитектуры. К этим

процессам относятся, в частности:

● документирование, рецензирование, информирование, изменение;

● проверка соответствия, поддержка актуальности;

● организация управления разработкой.

123

Метод Захмана

Метод Захмана является одной из ранних попыток связать характеристики ин

формационной системы с бизнесзадачами предприятия. Ни одна современная

организация не работает без системы или систем какоголибо рода, при помо

щи которых достигаются цели функционирования этой организации. Инфор

мационная система – это комбинация “ручных” и компьютерных процессов,

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

собой. В условиях современной конкурентной экономики использование раз

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

позиции в бизнесе.

Этот метод хорошо известен в мировой практике. Суть его сводится к форма

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

матрицы отображаются различные категории специалистов, определенным об

разом связанных с деятельностью предприятия (планировщик, собственник пред

приятия, проектировщик, разработчик и субподрядчик), а в столбцах – основ

ные аспекты производственной деятельности (объекты = что, действия = как,

местоположения = где, люди = кто, время = когда и мотивы = почему). Струк

тура матрицы изображена на рис. 7.3.

На рис. 7.4 изображена диаграмма, иллюстрирующая несколько главных

технологий моделирования, а также места их пересечения при формировании

матрицы Захмана. Каждая из этих моделей реального мира должна соответ

ствовать контексту общего направления бизнеса, которое определяется его

задачами, приоритетами и критическими для успеха факторами.

Использование моделей (рис. 7.5) на разных стадиях развития системы про

иллюстрировано в табл. 7.1.

Метод Захмана

От целей бизнеса к проекту

Объекты

(Что?)

Действия

(Как?)

Дислокация

(Где?)

Люди

(Кто?)

Врем

(Когда?)

Мотивы

(Почему?)

Планировщик

Сфера

действия

Владелец

предприятия

Модель

предприятия

Проектировщик

Системная

модель

Разработчик

Техническая

модель

Субподрядчик

Компоненты

архитектуры

Данные Функции Сеть Организация Расписание Стратегия

Элементы архитектуры предприятия

Рис 7.3. Формализованное представление модели предприятия по методу Захмана

Глава 7. Архитектура предприятия

124

В 1987 году Джон Захман опубликовал полезную схему развития архитекту

ры информационной системы. Такая схема создает контекст для описания раз

личных представлений архитектуры разрабатываемой системы. Эти представ

ления соответствуют тому, как видят систему ее заказчик, проектировщик

и разработчик, причем в разрезе трех выбранных аспектов, к которым относятся

данные, функции и сетевая структура. В схеме Захмана строке соответствует

Диаграммы

потоков

данных

Журнал

сущностной

динамики

Анализ

состояний

Функциональная

логика

Функциональные

иерархии

События

Сущностные

модели

Информация

Функции

Рис. 7.4. Типы моделирования

Цели, масштаб

проекта

Список того,

что важно

для бизнеса

Список процессов

бизнеса

Список областей

бизнеса

Модель бизнеса

Модель

информационной

системы

Модель данных Иерархия функций

Модель

архитектуры

системы

Технологическая

модель

Проектирование

данных

Модель

организационных

единиц

Оборудование,

программное

обеспечение

Детальное

представление

Полное описание

модели данных

Описание

программ

Схемы адресации

и используемых

протоколов

Функционирование

системы

Данные Функции

ДанныеМодели Функции

Связи

Диаграммы

“сущностьсвязь”

Диаграммы

потоков данных

Связь работ

Работы

Рис. 7.5. Модели развития системы

125

точка зрения какоголибо участника проекта по созданию системы. Аспекты

представлены в схеме колонками (рис. 7.5).

Архитектурное представление – это ячейка таблицы, соответствующая пере

сечению выбранных столбца и строки. Захман определяет архитектуру как пред

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

лиц. Таким образом, существует не одна архитектура, а некое множество архи

тектур. В зависимости от того, кем вы являетесь и на каком аспекте фокусиру

ете внимание, вы видите архитектуру системы поразному.

Заказчик видит систему с точки зрения общих стратегических и тактичес

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

или, напротив, его часть) и не всегда могут быть определены точно. Архитек

турные представления, соответствующие точке зрения заказчика, приведены

в двух верхних строках таблицы. Начальное планирование бизнеса и анализ

обычно определяют первые уровни детализации для этих архитектурных пред

ставлений. Цели бизнеса и его требования к системе полностью детализируют

каждое представление.

Представления проектировщика, несмотря на то что рассматривается одна и

та же система, существенно отличаются от представлений заказчика, причем не

только дополнительными деталями. Представления проектировщика – это про

ект системы, обеспечивающей удовлетворение требований, которые, в свою

очередь, описываются представлениями заказчика. Во многом представление

проектировщика добавляет точность, необходимую для тех, кто будет реализо

вывать систему, но представления проектировщика и заказчика остаются не

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

Структурный анализ, информационное моделирование и отдельные виды про

тотипирования являются теми методами, которые могут быть использованы

для формирования архитектурного представления проектировщика. Точке зре

ния проектировщика соответствует третья строка в схеме Захмана.

Метод Захмана

Таблица 7.1. Использование методов моделирования

Методы Уровень Системный Программный/

бизнеса уровень процедурный уровень

Функциональная иерархия о о о

Анализ состояний н о н

Диаграммы потоков данных н о н

Событийное моделирование н о о

Функциональная логика о о н

Примечание к табл.:

о – обязательное использование;

н – не обязательное, но возможное использование.

Глава 7. Архитектура предприятия

126

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

ненты каждого из технологически независимых взглядов, соответствующие

данным, функциям и сетевой структуре (три верхних строки), разрабатывают

ся одновременно командой, хорошо понимающей бизнес и имеющей опыт в соз

дании приложений и сетей, а также в администрировании данных. Хотя участ

ники могут представлять свою точку зрения (заказчик или проектировщик) или

фокусироваться на своих аспектах (данные, функции или сети), каждый вносит

свой набор знаний. Эти наборы в совокупности дают хорошую общую картину

требуемой системы. В достаточной степени проектировщики должны понимать

точку зрения заказчика и наоборот. Заказчик и проектировщик не могут разви

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

требований зависит от характеристик аппаратнопрограммной базы, выбран

ной для реализации системы. В отличие от желаемых логических связей, ре

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

знать, что мы хотим, перед тем, как делать вывод о невозможности чеголибо.

Технология ограничивает решения задач, а не их условия.

Важно помнить, что строки схемы представляют разные точки зрения, а не

разные уровни детальности представления. Для каждой ячейки таблицы мо

жет быть сделано многоуровневое описание. Необходимо понимать, что могут

возникать ситуации, в которых важно понятие взгляда, то есть совокупности

архитектурных представлений, находящихся в пределах одной строки.

Три аспекта, рассмотренных в схеме, приводят к различным архитектур

ным представлениям каждой из точек зрения. Аспекты соответствуют вопро

сам “Что?”, “Как?” и “Где?”, относящимся к конечному продукту (информаци

онной системе). Каждому аспекту соответствуют разные методы формирования

представления.

Колонка данных соответствует вопросу “Что?”. В строительстве, напри

мер, она соответствует списку материалов и частей, используемых при возве

дении здания, и взаимосвязям между этими частями. Внимание концентриру

ется не на том, из чего строится здание, а на том, как и где оно строится. Для

информационных систем вопрос “Что?” относится к сущностям данных и их

связям.

Колонка функций соответствует вопросу “Как?”. Она описывает, как ра

ботают отдельные части системы. В информационных системах функции обычно

определяются входами (элементы данных), процессами (преобразования) и вы

ходами (элементы данных). Внимание уделяется не столько отдельным частям

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

общей задачи.

127

Колонка сетевой структуры соответствует вопросу “Где?”. Архитектурные

представления в этой колонке описывают местоположение элементов систе

мы и механизмы их взаимодействия.

В целом схема Захмана является простым, но достаточно мощным сред

ством создания приложений и других необходимых компонентов ИТинфра

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

достаточно давно и ее применение вместе с современными стандартами может

вызвать трудности.

Метод Захмана

ГЛАВА 8

МЕТОДИКА СОЗДАНИЯ КОРПОРАТИВНЫХ

ИНФОРМАЦИОННОУПРАВЛЯЮЩИХ

СИСТЕМ

Проблематика построения корпоративных информационноуправляющих си

стем (КИУС) за последние годы привела к созданию самостоятельного направ

ления науки об управлении и развитию целой отрасли наукоемких технологий.

Последние годы отмечены качественным расширением понятия “система”,

широко используемого в международных комитетах и профессиональных со

обществах, ориентированных на информационные технологии. На современ

ном этапе под системой понимается “комплекс, состоящий из процессов, тех

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

возможностью удовлетворять установленным потребностям или целям”. Сле

дует сказать, что это определение достаточно близко к определению понятия

“автоматизированная система”, приведенного в ГОСТ 34.00390 (Информа

ционная технология. Комплекс стандартов и руководящих документов на авто

матизированные системы. Термины и определения): “в процессе функциони

рования автоматизированная система представляет собой совокупность

технических средств, организационнометодических и технологических доку

ментов и специалистов, использующих их в своей профессиональной деятель

ности”.

В стандартах присутствует и четкое определение понятия “ИТсистема”.

Так, в ГОСТ Р ИСО/МЭК ТО 10000199 информационнотехнологическая

система определяется как “набор информационнотехнологических ресурсов,

предоставляющий услуги по одному или нескольким интерфейсам”.

Для целей данной книги используется понятие КИУС, эквивалентное по

нятию ИТсистемы.

Информационная система предназначена для сбора, передачи, обработки,

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

ных компонентов:

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

● информационного обеспечения;

● технических средств;

● обслуживающего персонала.

129

Экономическими предпосылками создания и использования КИУС явля

ются:

● обеспечение гибкости рыночной стратегии;

● эффективное взаимодействие с партнерами;

● эффективная работа с клиентами;

● эффективное управление ресурсами и процессами;

● оперативное получение достоверной информации;

● анализ больших информационных объемов.

В современных условиях руководителей предприятий интересует:

● агрегация данных (а не обилие конкретных значений);

● динамика, перспективы, тенденции (а не статика);

● корпоративные решения (а не решения для подразделений);

● минимальные затраты на поиск требуемой информации;

● полнота и непротиворечивость информации;

● аналитические срезы для поддержки принятия решений.

С их стороны к корпоративным системам в современных условиях предъяв

ляются следующие требования:

● решение всего комплекса задач бизнеса;

● сбалансированная стоимость владения;

● широкие функциональные возможности;

● быстродействие и гибкость;

● безопасность.

Современный уровень развития информационных технологий, со своей

стороны, позволяет обеспечить:

● функциональную полноту;

● масштабируемость – система должна учитывать растущие потребнос

ти предприятия;

● гибкость – система должна настраиваться на изменения бизнеспро

цессов и внешней среды;

● стандартизацию и мобильность – компоненты системы должны функ

ционировать на различных аппаратных и системных платформах, а так

же быть взаимозаменяемыми компонентами аналогичной функциональ

ности;

● информационную безопасность;

● экономическую эффективность;

● независимость – с одной стороны, предприятие не должно попадать

в зависимость от поставщиков, с другой – не иметь собственного шта

та разработчиков.

Методика создания КИУС

130

Глава 8. Методика создания КИУС

Использование КИУС с точки зрения бизнеса обеспечивает увеличение

доходности, повышение конкурентоспособности, улучшение качества обслу

живания клиентов, снижение времени выпуска новых продуктов, полноту и не

противоречивость информации. С позиций технологии достигается консоли

дация данных и приложений, осуществляется естественная замена устаревших

унаследованных систем. Однако эффективность системы в первую очередь

зависит от того, насколько широко она охватывает все сферы деятельности

современного предприятия.

При создании КИУС единственно правильным решением для предприятия

является четкая расстановка акцентов – не подгонка задач предприятия под

возможности конкретного решения (то есть решение проблем производителей

систем), а выбор решения, соответствующего задачам бизнеса (то есть дости

жение собственных целей). Такая постановка вопроса требует проведения це

лого комплекса трудоемких и длительных исследовательских работ, предваря

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

● проверки соответствия существующего положения дел с уже имеющи

мися на предприятии информационными системами целям и задачам

бизнеса;

● разработки концепции создания КИУС;

● выявления, формирования и анализа требований к КИУС;

● выбора компонентов КИУС, наиболее полно удовлетворяющих этим

требованиям, и т.д.

Рассмотрим перечисленные задачи более подробно.

Проверка соответствия существующих программных систем задачам биз

неса. Целью этого мероприятия является оценка функциональности и техни

ческая оценка имеющихся на предприятии программных комплексов на пред

мет перспектив дальнейшего развития и использования в составе КИУС. В ходе

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

включающая идентификацию существующих информационных систем и под

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

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

лей и степень их удовлетворенности. Также должны быть рассмотрены вопро

сы взаимодействия со смежными системами, обеспечения информационной

безопасности комплекса, аппаратного обеспечения, условий эксплуатации и со

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

рассмотреть квалификационный, численный состав всей ИТслужбы, а также

ее структуру.

Текущее состояние информатизации должно быть проанализировано с точки

зрения эффективности ее использования и перспектив развития. При этом