Файл: Учебное пособие по дисциплине итинфраструктура предприятия (курс лекций) Направление подготовки 38. 03. 05 Бизнесинформатика.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 07.11.2023

Просмотров: 408

Скачиваний: 6

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

34 зволяющая классифицировать информационные системы в соответствии с бизнес-процессами, которые они обслуживают.
Классы информационных систем, как правило, воздействуют на не- большой набор бизнес-процессов компании, что позволяет легко выделить результаты их внедрения на предприятии и оценить в количественной или качественной форме.
Таблица 1.
Характеристики основных типов прикладных систем
Процессы с
большим
количест-
вом тран-
закций
Операции
в реаль-
ном вре-
мени
Аналитиче-
ские про-
цессы и
бизнес ана-
литика
Совмест-
ная рабо-
та
Корпора-
тивные
(обслужи-
вающие)
Страте-
гиче-
ские
потреб-
ности
Предостав- ление услуг.
Время ре- акции сис- темы.
Поддержка принятия решения.
Распреде- ление зна- ний.
Скорость.
Иннова- ции.
Надеж- ность.
Низкая стоимость с точки зрения ИТ.
Бизнес
требо-
вания
Обслужива- ние клиен- тов.
Уменьшение затрат.
Работа 24*7.
Целостность данных.
Экономич- ность и безопас- ность.
Работа
24*7*365.
Повышение эффективно- сти произво- дительности и нагляд- ность пре- доставления информации.
Скорость выпуска услуг.
Повторное использо- вание зна- ний.
Эконо- мичность.
Улучше- ние в про- цессах.
Отли-
читель-
ные ха-
ракте-
ристи-
ки.
Низкая стоимость
(одной тран- закции).
Надежность.
Масштаби- руемость.
Производи- тельность.
Резервиро- вание.
Сканиро- вание и фильтра- ция потока данных.
Приорите- зация за- просов.
Надеж- ность.
Публика- ция и под- писка на данные.
Механизм аналитики.
Мощность обработки.
Объединение данных.
Простота использо- вания.
Надеж- ность.
Высокая пропуск- ная спо- собность.
Стандарт- ные про- цессы.
Возмож- ность аут- сорсинга.
Интег-
ри-
рующие
Системы ин- теграции корпоратив-
Специаль- но разра- ботанный
Хранилища данных.
Совместно исполь- зуемые
Стандарт- ные ин- терфейсы.

35
техно-
логии
ных прило- жений. программ- ный код. данные и обмен данными.
Основной задачей области разработки прикладных систем являет- ся уменьшение стоимости создания и интеграции новых ИС и повышение их качества. Эти эффекты достигаются за счет использования единых подходов к разработке ИС (использование определенных архитектурных стилей) и оптимизации процесса разработки, что ведет к уменьшению об- щего количества различных технических сценариев, связанных с проекти- рованием архитектуры, операционной поддержкой и интеграцией инфор- мационных систем.
Таким образом, при внедрении новой ИС область разработки при- кладных систем обеспечивает выбор технологий и принципов (дизайн ре- шения), реализацию и сопровождение, а портфель прикладных систем обеспечивает непосредственно процесс внедрения.
Портфель прикладных систем описывает потребности бизнес- процессов предприятия в информационных технологиях и включает в себя набор интегрированных информационных систем (рисунок 11.).
Рисунок 11. Портфель прикладных систем
Текущий профиль информационных систем (existing portfolio) – описывает существующие приложения, компоненты, интерфейсы, связан- ные с ними бизнес-процессы, и является текущей архитектурой прило-
жений.
Планируемый профиль информационных систем (planned portfo- lio) – описывает необходимую для бизнеса функциональность в будущем, и является целевой архитектурой приложений.
План миграции (migration planning) - это документ, описывающий набор изменений, необходимых для перехода из текущего состояния в планируемое (целевое). На основании плана миграции активируются про-


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

Вывод из эксплуатации, замена (phase out / replace).

Переоценка необходимости (re-evaluate / reposition).

Разработка новой инфраструктуры (application infrastructure development).

Обеспечение сопровождения и развития (maintain / evolve).
Анализ портфеля инвестиций в прикладные системы может быть осуществлен с помощью «принципа ценности приложения для выполнения ключевых функций организации». В соответствии с этим подходом можно выделить приложения, наиболее необходимые для функционирования бизнеса.
Уровень необходимости ИС для бизнеса компании или, другими словами уровень критичности ИС, непосредственно связан с их надежно- стью.
Надежность информационных систем характеризуется прямой зави- симостью количества отказов за определенный промежуток времени, на- прямую зависит от качества программно-аппаратных средств и уровня ре- зервирования. То есть, надежность ИС напрямую зависит от финансовых затрат на них. Появляется классическая зависимость – чем выше затраты на ИС, тем выше надежность подобной системы. Для сокращения затрат на ИТ можно снизить надежность отдельных ИС, не являющихся критич- ными для предприятия. Все ИС можно распределить по нескольким уровням в соответствии с их важностью (критичностью) для компании по следующим критериям:
1.
Компания перестает предоставлять услуги клиентам. Данный критерий представляется наиболее важным для функционирования ком- пании. Простой предприятия влечет не только финансовые потери, но и возможные потери клиентов, и судебные иски с их стороны.
2.
Компания несет существенные финансовые потери. Основная цель любой компании – получение прибыли и, соответственно, минимиза- ция возможных убытков.
3.
Большое количество сотрудников (свыше 500) не может вы- полнять свои непосредственные обязанности. Подобная ситуация может привести к совершенно неожиданным потерям для предприятия.
В соответствии с представленными выше критериями все ИС на предприятии можно разделить на следующие уровни критичности:

37
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:

прочие системы.


38
Подход к определению уровня критичности систем:
1.
Определение перечня основных бизнес-процессов предпри- ятия, остановка функционирования которых парализует работу компании или ведет к существенным финансовым потерям.
2.
Анализ существующих ИС и их взаимосвязь с основными биз- нес-процессами компании. Определение важности тех или иных ресурсов
(информационных систем и их компонентов) для функционирования ос- новных бизнес-процессов компании.
3.
Построение общей модели информационных систем, опреде- ляющей взаимосвязи между информационными, программными, техниче- скими и людскими ресурсами, их взаимное расположение и способы взаимодействия.
4.
Определение финансовых потерь, связанных с остановкой ИС и вероятность их возникновения.
5.
Оценка уровня критичности ИС для функционирования пред- приятия на основании информации собранной на предыдущих шагах.
Техническая архитектура предприятия (ETA)
Техническая архитектура предприятия (ETA - Enterprise Technical
Architecture) – это совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование прило- жений. Другими словами, под технической архитектурой мы будем пони- мать полное описание инфраструктуры предприятия, включающее в себя:

Информацию об инфраструктуре предприятия.

Системное программное обеспечение (СУБД, системы инте- грации).

Стандарты на программно-аппаратные средства.

Средства обеспечения безопасности (программно-аппаратные).

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

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

Сервисы данных: системы управления базами данных, храни- лища данных, системы поддержки принятия решений (Business Intelli- gence).

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

Программное обеспечение промежуточного слоя.

Вычислительная инфраструктура: операционные системы и аппаратное обеспечение.

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

Сервисы безопасности, авторизация: аутентификация, сете- вая безопасность, физическая безопасность центров обработки данных.


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

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

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

41

Деятельность по реализации процесса. o
Управление CI. o
Расчет контроля и статуса. o
Отчеты о данных CMDB. o
Подтверждение сохранности данных CMDB.

Деятельность по контролю качества. o
Загрузка исходных данных CMDB. o
Создание системы управления конфигурацией. o
Разработка контрольной политики CI. o
Составление административных отчетов. o
Непрерывное совершенствование процесса.
Данные процесса управления конфигурациями обычно хранятся в базе данных Configuration Management (CMDB) и включают в себя ин- формацию об инцидентах, проблемах, изменениях, релизах и связях меж- ду ними.
Бизнес пользователи, клиенты
Сообщения о сбоях, вопросы, затруднения
Ответы на вопросы, обновления, обходные пути
Изменения
Релизы
Служба поддержки
Отчет по запросам пользователей
Инциденты
Инциденты
Инструменты управления
Управление инцидентами
Управление проблемами
Управление изменениями
Управление релизами
Управление конфигурациями
Связь элементов конфигурации
Релизы
Изменения
Проблемы, известные ошибки
Инциденты
Статистика по инцидентам.
Отчетность по инцидентам.
Статистика по проблемам.
Анализ тенденций.
Расписание изменений.
Статистика по изменениям.
Расписание релизов.
Статистика по релизам.
Отчеты по
CMDB.
Стандарты ведения CMDB.
CMDB
CMDB
Рисунок14. Управление конфигурацией (Configuration Management)
Таким образом, эффективно работающий процесс управления кон- фигурациями обеспечивает большую часть информации, необходимой для построения текущей архитектуры предприятия и является элементом ар- хитектурного процесса.


42
1   2   3   4   5   6   7   8   9   ...   15