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

155

Создание системы контроля

Составление административных отчетов

Непрерывное совершенствование процесса
Управление проблемами
Процесс Управления проблемами (Problems Management) носит пре- вентивный характер. Он направлен на снижение числа неполадок произ- водственной среды и реализуется путем изучения источников их возник- новения (на основе информации о прошлых инцидентах). Он также вклю- чает анализ тенденций и контроль известных ошибок с расчетом на устра- нение их источников в долговременной перспективе. Этот процесс тесно связан с процессом Управления инцидентами, так как он отчасти имеет дело с рассмотренными Службой помощи инцидентами и информирует другие процессы о потенциальных проблемах в инфраструктуре.
Деятельность по реализации процесса:

Анализ тенденций в возникновении проблем

Регистрация проблем

Выявление источника

Отслеживание истории проблем

Анализ известных ошибок

Контроль известных ошибок

Решение проблем

Закрытие дел по проблемам/известным ошибкам
Деятельность по контролю качества:

Создание системы контроля проблем/известных ошибок

Установка и поддержание контактов поддержки

Создание превентивных процедур технического обслуживания

Разработка методов анализа известных ошибок

Создание интерфейсов поддержки поставщиков

Составление административных отчетов

Непрерывное совершенствование процесса
Управление изменениями
Процесс Управления изменениями (Change Management) регистри- рует все значительные изменения в производственной среде, координиру- ет порядок работ, связанных с изменениями, задает приоритет запросам на их внесение, дает полномочия на производственные изменения, составля- ет графики ресурсов и оценивает риск, связанный с изменениями, а также их влияние на ИТ-среду. Имея представление об этом процессе, легко по- нять, почему он связан со всеми остальными процессами модели. Во вре- мя своей работы каждый процесс неминуемо вносит какие-то перемены в
ИТ-среду. Управление изменениями - один из процессов, который регули- рует подобные изменения, ведет контроль и записи, повышая таким обра- зом стабильность инфраструктуры.

156
Деятельность по реализации процесса:

Обработка запросов на изменения

Оценка влияния

Одобрение изменений

Составление графиков и координация изменений

Координация восстановления в случае неудачного прохожде- ния изменений
Деятельность по контролю качества:

Создание процесса по приему запросов на внесение изменения

Определение схем категорий и приоритетов изменений

Создание процесса управления "проектами" изменений

Создание комитета по совету о внесении изменений

Проведение осмотра после внесения изменения (ретроспектив- ного

Составление административных отчетов

Непрерывное совершенствование процесса
Управление конфигурацией
Процесс Управления конфигурацией (Configuration Management) ИТ ведет централизованную регистрацию и осуществляет контроль над ин- формацией об инфраструктуре, такой как атрибуты единицы конфигура- ции (Cl - Configuration Item) (например, определение системного и сетево- го оборудования, производственного программного обеспечения, людей
(сотрудников), документации, и т. п.), статус CI (например, на складе, в ремонте, в производстве и т. п.) и их взаимоотношения (типа: у пользова- теля X на столе ПК А; принтеры В, С, и D готовы к печати; вопрос попа- дает под раздел "SLA онлайнового шопинга 10.1" и т. п.). Обратите вни- мание, что на первый взгляд этот процесс легко перепутать со стандарт- ным управлением ресурсами. Но это не так. Процесс Управления конфи- гурацией отличается от Управления корпоративными ресурсами тем, что он целиком направлен на ИТ-инфраструктуру и позволяет делать запросы о параметрах инфраструктуры, основываясь на отношениях. Любой дру- гой ИТ-процесс, затрагивающий инфраструктуру, находится во взаимо- связи с этим процессом.
Данные конфигурации обычно хранятся в базе данных Configuration
Management (CMDB).
Деятельность по реализации процесса:

Управление CI

Расчет контроля и статуса

Отчеты о данных CMDB

Подтверждение сохранности данных CMDB

157
Деятельность по контролю качества:

Загрузка исходных данных CMDB

Создание системы управления конфигурацией

Разработка контрольной политики CI

Составление административных отчетов

Непрерывное совершенствование процесса

158

159
• Автоматизация отдельных участков (или бизнес-процессов) по- средством внедрения отдельных модулей, входящих в один или в разные продукты.
Перечисленные примеры позволяют сделать вывод, что стратегия включает в себя ответы на ключевые вопросы о процессе внедрения и ис- пользования информационных технологий:
• Комплексность автоматизации.
• Если не предполагается комплексная автоматизация, то определе- ние направлений деятельности, бизнес-процессов или подразделений, ко- торые будут автоматизироваться.
• Порядок автоматизации, сроки отдельных этапов.
• Выбор используемых продукт®, систем, платформ.
• Применение заказных разработок.
• Используемые методики интеграции.
• Способы реализации проектов (использование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразде- ления и лр.).
• Способы поддержи основных ИТ-сервисов (традиционный, SLA).
Также как ИТ-стратегия конкретизирует общую стратегию предпри- ятия с точки зрения ИТ так и ИТ-архитектура рассматривает НТ-аспекты общей архитектуры предприятия. Определение архитектуры предприятия дано в стандарте ANSI/IEEE Sid 1471-2000: «фундаментальная организа- ция системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих ее конструкцию й разви- тие». Архитектура предприятия - это концептуальное средство, которое помогает организации понять свою структуру и способы работы. Обычно архитектура предприятия имеет форму большою набора взаимосвязанных моделей, описывающих структуру и функции предприятия.
Весь набор моделей архитектуры предприятия можно условно раз- делить на четыре категории:
Бизнес-ракурс. Бизнес-ракурс описывает бизнес предприятия. Сюда включаются бизнес-стратегии и планы по переводу предприятия из теку- щего состояния в планируемое состояние в будущем. В типовом случае этот ракурс включает:
• Цепи и задачи верхнего уровня.
• Бизнес-процессы, охватывающие всё предприятие или значитель- ную ею часть.
• Выполняемые бизнес-функции.
• Основные организационные структуры.
• Взаимосвязи между всеми перечисленными элементами.
Бизнес ракурс распространяется на все аспекты деятельности пред- приятия. Сюда входит технология производства, используемые финансо-

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

161 ции. С этого ракурса определяется набор технологических стандартов и сервисов, необходимых для выполнения бизнес-миссии.
Хотя архитектура предприятия может содержать и большее число ракурсов, у каждого предприятия имеется только одна архитектура, кото- рая описывает перспективу его развития. Значение архитектуры предпри- ятия не определяется каким-то одним частным ракурсом, а состоит в оп- ределении взаимоотношений, взаимодействий и взаимозависимостей ме- жду различными ракурсами.
ИТ-архитектура предприятия (организации), являющаяся частью общей архитектуры, включает в себя ракурс приложений и технологиче- ский ракурс. Поэтому, рассматривая соответственно ИТ-архитектуру, мы можем говорить об архитектуре приложений и технологической архитек- туре предприятия (организации).
Как архитектура приложений, так и технологическая архитектура состоят из концептуального представления, логического представления и физического представления.
Концептуальное представление является наиболее абстрактным и тя- готеет к описанию в терминах, которые более понятны пользователям системы, не являющимся ИТ-профессионалами. Концептуальное пред- ставление используется для определения функциональных требований и для построения бизнес-модели на основе представления бизнес- пользователей приложений. Для построения описания ключевых бизнес- процессов и используемых ими данных используются такие техники кон- цептуального моделирования, как анализ юскейсов, диаграммы деятель- ности, моделирование бизнес-сущностей и тд. Всё это направлено на то, чтобы удовлетворить бизнес-цели и бизнес-требования и не зависит от технологий реализации.
Логическое представление показывает основные функциональные компоненты и их взаимосвязи внутри системы без определения техниче- ских деталей реализации необходимой функциональности. Архитекторы создают модели приложений, которые являются логическим представле- нием бизнес-моделей, поскольку они определяют как удовлетворить биз- нес-цели и бизнес-требования. Модели приложений представляют собой логические представления архитектуры приложений. Архитекторы в дан- ном случае работают с общей структурой приложений. Они решают, как будет отображаться управление данными и шаги бизнес-процессов, они проектируют взаимодействие между компонентами модели в терминах логических сообщений и последовательностей, и они определяют, какие данные и состояния может содержать модель.
Физическое представление - является наименее абстрактным и ил- люстрирует специфику реализации компонентов и взаимосвязей между ними. Каждый элемент физического представления реализуется в процес-

162 се проектирования и разработки как программный или аппаратный ком- понент. Каждый элемент модели приложения должен быть поставлен в соответствие элементам реально существующих технологий. Этим спосо- бом модели приложений преобразовываются в модели реализации. Часть этих задач выполняется во время традиционной разработки, когда про- граммисты прописывают детальную бизнес-логику в виде программного кода, но множество действий по реализации хорошо классифицируются как действия по применению специализированной среды. Это такая тех- ника разработки, в которой множество элементов инфраструктуры рас- пределённых приложений и управления данными поддерживается специа- лизированной средой, которая расширяет пользовательскую логику при- ложений и декларативные структуры управления. Применение специали- зированной среда скрывает от разработчика множество сложностей, на- пример, поддержку асинхронного режима приёма-передачи сообщений, а также позволяет разработчику с невысоким профессиональным уровнем реализовывать сложные проекты.
После того, как мы дали определение ИТ-архитекгуре, проанализи- руем взаимосвязь между ИТ-стратегией и ИТ-архитектурой. Эта взаимо- связь адекватна взаимосвязи между общей стратегией развития предпри- ятия и архитектурой предприятия. Стратегия имеет более общий характер, не так детально рассматривает отдельные аспекты, как архитектура. И в отличие от архитектуры стратегия продолжительна во времени. На оси времени архитектура отражает какой-то конкретный момент, а стратегия - период. Можно сказать, что стратегия описывает последовательность пре- образования архитектуры во времени. При этом каждая конкретная архи- тектура в этой последовательности рассматривается не детально, а только в общих чертах.
Однако ИТ-стратегая не сводится к описанию последовательности преобразований ИТ-архитектуры. Описание в ИТ-стратегии процесса раз- вития ИТ-архитектуры во времени требует, чтобы в составе стратегии бы- ло дано общее направление этого развития, разработаны общие принципы развития, определены критерии достижения заданной цепи и требуемые ресурсы.
2.
Состав работ по разработке ИТ-стратегии и ИТ-
архитектуры
Разработка ИТ-стратегии
Разработка ИТ-стратегии может осуществляться как в сочетании с последующей детальной разработкой ИТ-архитектуры на ближайшую перспективу, так и без этого этапа. Состав работ по разработке собственно
ИТ-стратегии: