авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 2 | 3 || 5 |

«РОССИЙСКАЯ ФЕДЕРАЦИЯ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ...»

-- [ Страница 4 ] --

- Подготовлены модели процессов - Используются шаблоны, гарантирующие непротиворечивое фиксирование информации Рабочий - Классификация существующих стандартов технологии явля проект ется непротиворечивой - Документированные бизнес - факторы и стратегическая ин формация являются непротиворечивыми Коммуни- - Эффективно определена и опубликована архитектура кация - Для высшего руководства проводится обучение архитектуре и ее эффекту - Организовано обучение членов комитетов по АП Согласова- - Ясно определен формализованный процесс согласования АП, ние который является неотъемлемой частью процесса жизненного цикла АП - Последовательно по всему предприятию сопровождается процесс согласования АП - Требуется экономическое обоснование при отклонении АП от стандартов Интеграция - Программа АП интегрирована со стратегическим планирова нием и бюджетированием - Определены точки соприкосновения процесса управления и АП Участие - Организация начинает действовать как группа, используя оп ределенную программу архитектуры и стандарты - Высшее руководство участвует в различных комитетах по АП - Деловой и технический персонал участвует в комитетах по АП PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 4 Категории Описание категорий Управляе мая про грамма Админист- - По ролям и обязанностям управления делается обзор и обновле На этом уровне показатели производительности измеряюися, анализируются и используются в управлении. Показатели ис рирование ние, которые включаются во фреймворк АП Планиро- - Делается обзор по планам АП и изменения включаются в про пользуются, чтобы предсказать производительность и обеспечить лучше понимание процессов и возможностей.

вание грамму - Организация использует показатели для измерения прогресса по отношению к существующим планам АП Фреймворк - Организация использует показатели для оценки эффективности процессов АП и шаблонов - Когда обнаружены ошибки в шаблонах и/или процедурах, пла ны управляющего воздействия вводятся в действие - Проводятся регулярные встречи для создания обзора модифика ций, Рабочий - Документирование бизнес - факторов и стратегической инфор проект мации стала стандартной практикой - Стало стандартной практикой документирование классификации продуктов и согласований - Чтобы идентифицировать потребность в обновлениях, организа ция фиксирует показатели процесса согласования Коммуни- - Процесс коммуникации формализован и сопровождается кация - По процессу коммуникации делается обзор, при этом изменения включаются в АП - Проводится обязательное обучение персонала по АП - Организация фиксирует показатели, на основании которых про водится оценка процесса коммуникации АП Согласова- - Согласование со стандартом АП стало нормой во всем предпри ние ятии - Зафиксированы качественные показатели, связанные с экономи ческим обоснованием - По процессу согласования делается обзор, результаты которого сохраняются Интегра- - Архитектура предприятия используется для проведения разрабо ция ток и закупок - Организация фиксирует показатели, чтобы измерить экономию ресурсов, включая время и деньги - При определении проекта рассматриваются затраты и эффект - Процесс анализируется и обновляется после интеграции Участие - Весь штат организации хорошо пониманиет руководителей ар хитектуры и участвует в процессах АП, например, в качестве членов комитетов - В организации фиксируются показатели, измеряющие понима ние, участие, принятие и удовлетворение программой АП PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 5 Катего- Описание категорий Непрерыв- рии ное улуч шение про граммы Админи- - Комитеты по управлению проактивно делают обзор своих потребностях. Существует непрерывное улучшение и исправление, основанное на понимании изменений воздейст Процессы зрелы;

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

шаблонах используются измеряемые показатели - Чтобы совместно использовать идеи усовершенствования процессов АП и шаблонов, организация работает с другими структурами Рабочий -По фиксированному бизнесу и технической информации де проект лается обзор вместе с мониторингом новых технологий и тен денций в области бизнеса, чтобы проактивно идентифициро вать технологию, способную улучшить бизнес -Организация работает с другими структурами для, чтобы поделиться информацией относительно тенденций техноло гии и бизнеса Комму- - Показатели используются, чтобы проактивно идентифици никация ровать возможности улучшения коммуникации - Организация работает с другими структурами для совмест ного использования идеи усовершенствований процессов связи Согласо- -Информация, собранная во время процесса согласования, ис вание пользуется, чтобы проактивно идентифицировать обновления стандартов АП и/или фреймворков -Показатели архитектуры используются, чтобы управлять не прерывным усовершенствованием процесса экономических обоснований -Организация работает с другими структурами, чтобы совме стно использовать идеи усовершенствования процесса согла сования PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 5 Катего- Описание категорий Непрерыв- рии ное улуч шение про граммы Интегра- - Процесс архитектуры предприятия управляет процессом не ция прерывного обновления всего предприятия - Бизнес влияет на технологию, а технология влияет на бизнес - Зафиксированные показатели используются, чтобы проак тивно идентифицировать усовершенствования структуры АП или информации проекта и/или процессов интеграции.

- Организация работает с другими структурами, чтобы совме стно использовать идеи улучшения интеграции, включая дей ствия по приобретению и руководству проектом Участие - Агентства и отделы сотрудничают по работе с архитектурой и ее процессами - Организация использует зафиксированные показатели, что бы проактивно создать планы действия относительно усовер шенствования маркетинга АП и образовательных программ - Организация работает с другими структурами, чтобы совме стно использовать идеи создания атмосферы активной прича стности и участия в программе АП и кросс-функциональных процессах Фреймворк Дж. Захмана архитектуры предприятия (Frame work Zachman Enterprise Architecture)/43-45/ Фреймворк архитектуры предприятия, разработанный Дж. Захманом (John A. Zachman)52 (иногда просто называют "Модель Захмана"), стал фак тическим стандартом классификации и разработки артефактов архитектуры уровня предприятия. Он построен на основе таких дисциплин, как классиче ская архитектура, конструирование, инженерия и производство. Это дает возможность сформировать общий словарь и набор проекций фреймворка для определения и описания современных сложных систем предприятия.

Модель представляет логическую структуру для классификации и организа Первая публикация модели датируется 1987 г., в -90г. модель дорабатывалась.

PDF created with pdfFactory Pro trial version www.pdffactory.com ции тех элементов предприятия, которые являются существенными как в управлении предприятием, так и в разработке ее информационных систем.

Начиная с его первых публикации в 1987г., фреймворк Захмана был развит и фактически стал методологией, на основе которой ведущие органи зации всего мира создают свою информационную инфраструктуру предпри ятия. Модель Захмана послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как: Феде ральная Архитектура США (FEAF – Federal Enterprise Architecture Framework);

методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), разобранная выше;

методика описания архитектуры Министерства обороны США (DoDAF – Department of Defence Architecture Framework).

Фреймворк Захмана включает матрицу 6x6 матрица (рисунок 4.17) Рисунок 4.17 Официальная версия модели Захмана (zifa.com).

PDF created with pdfFactory Pro trial version www.pdffactory.com При этом, модель фактически не охватывает последнюю строку. Дан ная строка не детализирована и представлена только названиями функций предприятий. Это говорит о том, что эта строка соответствует не уровню по строения архитектуры предприятия, а уровню работы предприятия. В тоже время, присутствие данной строки дает возможность сделать ретроспективу процессов при построении архитектуры на функции предприятия.

В организации модели определяется два измерения (Рисунок 4.18):

• ролевая точка зрения участников проекта создания архитектуры:

o планировщик, владелец, дизайнер, конструктор, разработчик • абстракции архитектуры:

o Что? Как? Где? Кто? Когда? Почему?

Рисунок 4.18 – Организация модели Захмана.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 4.18 – Детализация модели Захмана (по материалам http://apps.adcom.uci.edu/EnterpriseArch/Zachman/zachman.jpg) PDF created with pdfFactory Pro trial version www.pdffactory.com Фактически, модель Захмана дает ответ на шесть главных вопросов в пяти уровнях абстракции. Как тут не вспомнишь Киплинга:

«Есть у меня шестерка слуг, Проворных, удалых, И все, что вижу я вокруг, Все знаю я от них.

Они по знаку моему Являются в нужде.

Зовут их: Как и Почему, Кто, Что, Когда и Где…»

Описание ячеек во фреймворке архитектуры предприятия дано ниже53.

Область 1: "Что? - Данные" Уровень 1: "Список вещей, важных для бизнеса" Это просто список вещей (или объектов, или активов), интересных для предприятия c точки зрения "предметной области". Этот список определя ется на высоком уровне агрегации. Он определяет область или границы мо делей вещей, представленных в строках 2-5, которые являются существен ными для Предприятия.

Уровень 254: "Семантическая модель" Модель фактических вещей предприятия (объекты, актив) является су щественной для его описания. Типичное представление семантической моде ли - модель "Сущность - связь" (ER). Она определенна на уровне абстрак Текст описания ячеек модели Захмана построен по материалам «The Framework for Enterprise Ar chitecture Cell Definitions» (ZIFA 03.doc ©- Zachman Institute for Framework Advancement) http://apps.adcom.uci.edu/EnterpriseArch/Zachman/ZIFA03.pdf, который может быть использован только в учебных целях Строки со второй по пятую в каждом столбце описаны как один из возможных примеров реализации данного уровня для данного столбца. Предполагается, что существуют другие возможности, которые не публикуются в открытой литературе.

PDF created with pdfFactory Pro trial version www.pdffactory.com ции, которая позволяет отобразить понятия (сроки и факты), используемые в стратегических бизнес - целях для определения как "Бизнес - правил."

Уровень 3: "Логическая модель данных" Модель логического (технология реализации не существенна) пред ставления сущностей предприятия, по которым сохраняется информация (автоматизировано или вручную). Фактически, это развитие нормализован ной семантической ER модели, в которой определены атрибуты и ключи.

Уровень 4: "Физическая модель данных" Данная модель определяется технологией реализации. Стиль представ ления этой модели зависит от технологии, выбранной для реализации. Если выбирается реляционная технология, то структура представляется в виде двумерных таблиц, в объектно-ориентированном представлении - моделями классов.

Уровень 5: "Определение Данных" На этом уровне определяются все объекты данных, специфицирован ные в физической модели, включая язык определения данных, требуемый для реализации.

Область 2: "Как? - Функция" Уровень 1: "Список процессов на предприятии" Это список процессов (или функции), преобразующих вход в выход, который выполняется на предприятии. Список может быть определен на вы соком уровне абстракции. Он определяет область или границы моделей про цессов предприятия, приведенных в строках со 2 по 5.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Уровень 3: "Архитектура приложения" Модель логической реализации (не зависит от технологии) "систем" (ручных и/или автоматизированных) поддержки бизнес-процессов, которые имеют, по возможности, быстродействующий "человеко-машинный" интер фейс. Желательно включить в модель, помимо "входов и выходов" процес сов (или функций), "средства управления и механизмы".

Уровень 4: "Проект системы" Технически, проект системы нельзя отнести к "моделям", поскольку здесь не ставится задача отображения предприятия. На высоком уровне абст ракции можно отразить структурную схему55 и ее детали, а также "диаграм мы деятельности"56,которые дают стилевое решение реализации логической системы или "архитектуры приложений." В Объектно-ориентированной но тации проект системы может быть описан методами и их реализацией.

Уровень 5: "Программы" Программы вытекают из диаграмм деятельности, которые представля ют спецификацию для реализации стилевых решений реализации (структур ных или объектно-ориентированных). Это кандидаты в "компоненты", кото рые могут быть "тиражированы" более, чем в одной реализации.

Область 3: "Где? - Сеть". Уровень 1: "Территориальное расположение" Структурная схема - схема, показывающая взаимодействие компонентов или других частей системы В оригинале диаграммы действий Для каждой области существует схема отношений с другими областями. Это особенно характерно для области "Сетевая архитектура". В узлах сети хранятся данные (связь с первой областью), в них осуществляется обработка (связь со второй областью), им свойственна логика представления (связь с четвертой областью). Параметры полученные из связанных областей, определяют производительность сети и, следовательно, модели третьей области.

В модели Захмана указывается, что для данной области может использоваться нотация приведенная в книге Берни Боар (Bernie Boar ) "Создание рабочего проекта ИТ архитектура предприятия". В ней приводятся нотации для области данных и области обработки.

PDF created with pdfFactory Pro trial version www.pdffactory.com Список мест, в которых располагается предприятие, или же географи ческое положение объектов, связанных с данной темой обсуждения. Данный список может быть определен на высоком уровне агрегирования. Он опреде ляет область или границы моделей размещения и связи уровня предприятия, показанные в строках со 2 по 5.

Уровень 2: "Логистическая сеть" Модель дислокации предприятия, схема соединения его частей и средств доставки (голосом, данными, почтой или багажом по железной до роге, водным путем или на автомобиле). Модель включает идентификацию типов средств обслуживания в таких узлах как отделение, головной офис, склады и т.д.

Уровень 3: "Архитектура распределенной системы" Это логическая модель (не зависит от технологии) системной реализа ции логистической сети, показывающая типы средств системы и управления программным обеспечением в узлах и на линии связи (процессо ры/операционные системы, запоминающие устройства / СУБД, периферий ные устройства/драйверы, операционные системы линии связи/линии связи, и т.д.) Уровень 4: "Архитектура системы (Технологическая архитектура) " Описание физических объектов технологической среды предприятия, показывающее аппаратное и программное обеспечение систем в узлах и ли ниях связи и их системном ПО, включая операционные системы и ПО про межуточного слоя.

Уровень 5: "Архитектура сети" Определение специфики адресов узла и идентификация линии связи.

Примечание для областей 1, 2 и 3: Современное техническое разви тие оказывает большое влияние на описание уровней этих областей. Это обусловлено значительным усложнением управления распределенной сре дой ("клиент-серверный") в отличие от среды с единой обработкой (майн PDF created with pdfFactory Pro trial version www.pdffactory.com фрем). В настоящее время формализм описания этих областей становится скорее проблемой, чем достоинством информационных технологий.

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

Область 4: "Кто? Люди" Уровень 1: "Список организаций, важных для бизнеса" Реестр административной и функциональной структуры предприятия с определением ответственности за выполняемые работы. Он определяет об ласть исследования, связанную с людьми. Данный список может формиро ваться на высоком уровне агрегации.

Уровень 2: "Модель делопроизводства" (Модель потока работы) Модель отражает распределение работ, действующих на предприятии, со спецификацией их результатов. Данная модель может отражать организа ционную структуру. Для каждого организационного модуля должен быть определен результат его деятельности и модуль, который использует этот ре зультат.

Уровень 3: "Архитектура пользовательского интерфейса" Логическое представление "систем" потоков работы (совокупность мо делей делопроизводства), которое включает спецификацию ролей исполни теля (менеджер, администратор, специалист в сфере анализа и обработки ин формации, разработчик, маркетолог и т.д.) и спецификацию продукта на ло гическом уровне (голос, текст, графика, видео и т.д.).

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

Уровень 5: "Архитектура безопасности" PDF created with pdfFactory Pro trial version www.pdffactory.com Спецификация регламента доступа к системе, с определением доступ ных для инициализации работ и заданий.

Столбец 5: "Когда? Время" Уровень 1: «Список событий, существенных для бизнеса»

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

Уровень 2: "Главный производственный график" Модель бизнес - циклов, состоящая из событий инициализации и фак тически затраченного времени ("цикл"). Для отображения этой модели ис пользуются обычно две нотации: PERT и Senge.

Уровень 3: "Технологическая структура" Логическая спецификация системы (т.е. не зависит от технологии опи сания), которая включает точки во времени (события в системе) и временные интервалы (цикл исполнения). Эта модель описывает системные события, которые вызывают состояние перехода от одного допустимого состояния к другому (точка вовремя), а также динамику цикла перехода. Данные модели представлены в нотации диаграммы жизни объекта (из методологии SSADM) или в нотации диаграммы состояния (в объектно-ориентированном подходе).

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

Уровень 5: "Определение временных диаграмм" На данном уровне определяются прерывания и циклы машинной обра ботки.

PDF created with pdfFactory Pro trial version www.pdffactory.com Область 6: "Почему? Мотивация" Уровень 1: "Список бизнес целей /стратегий" Список главных бизнес - целей, стратегий или критических факторов успеха предприятия. Так называемая, область, определяющая мотивацию.

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

Уровень 2: "Бизнес-план" Модель бизнес - целей и стратегий предприятий ("результат" и "сред ства"). Существуют значимые академические центры в области теории управления, тем не менее, сегодня нет общепринятых нотаций, используе мых для этих моделей.

Уровень 3: "Бизнес правила" Это логическая модель бизнес - правил предприятия в терминах их замыслов ("результат") и ограничений ("средств"). В настоящее время нет общепринятой нотации для отображения бизнес - правил. В тоже время, су ществуют нотации: модель бизнес правил Ron Ross (Business Rules Models), язык объектных правил Terry Halpin (Object Rule Language ) и язык правил и ограничений Bob Brown (Rule and Constraint Language ).

Уровень 4: "Проект правил" Это физическая спецификация бизнес - правил. Правила, в этом случае, не раскладываются на составляющие элементы и находятся из мощности множества и функциональных возможностей моделей данных (область 1), процедурного кода (область 2) или спецификации политики (область 4). Для описания проекта правил может использоваться "механизм логического вы Исторически, правила были встроены в структуру данных (область 1), спецификацию процессов (область 2) или административной политики (область 4). Данная область основана на том, что есть необходимость использовать бизнес – правили, как независимые переменные, в силу того, что их влияние на поведенческие особенности предприятия значительно.

PDF created with pdfFactory Pro trial version www.pdffactory.com вода", как технология выражения правил, независимо от данных, логики и инструментальных средств.

Строка 5: "Спецификация правил" Спецификация бизнес - правил в отрыве от контекста.

Описание архитектуры ПО (Архитектура 4+1) Приведем в качестве примера архитектурное описание программного обеспечения, предложенное Ф. Крачтеном /53/ (рисунок 4.19).

Реализационное Логическое представление представление Программист Аналитик/дизайнер Конечный Управление разработкой и Структуры пользователь Прецедентное сопровождения ПО Функциональные представление возможности Процедурное Представление представление развертывания Системный интегратор Системотехника Эффективность, Топология системы, масштабируемость, распространение, производительность установка, связь Рисунок 4.19- Архитектура 4+1.

Основное внимание логическое представление (logical view ) акценти рует на концептуальной структуре системы. Это абстракция модели проек тируемой системы, определяющая главные пакеты, подсистемы и классы мо дели, и их отношения. Это системное представление с точки зрения аналити ков и проектировщиков. Данный уровень не затрагивает вопросы реализации системы.

PDF created with pdfFactory Pro trial version www.pdffactory.com Представление реализации (implementation view ) описывает структуру статических программных модулей в среде разработки в терминах организа ции пакетов и уровней, а также описывает управление конфигурацией. Дан ное представление выполнено с точки зрения программистов, реализующих основные модули системы.

Представление развертывания (deployment view ) показывает, каким образом различные исполняемые файлы и другие компоненты времени вы полнения устанавливаются на используемых платформах или в узлах вы числительной сети. Данное представление выполнено с точки зрения систе мотехников, решающих вопросы топологии системы, развертывания ее и ор ганизации компьютерных сетей.

Процедурное представление (process view) акцентирует внимание на аспектах параллельного выполнения процессов системы: организация регла мента решения задач, управления потоками или процессами, а также вопро сами взаимодействия других элементов.

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 5. Стандарты и фреймворки59, используемые в области ИТ сервис менеджмента Библиотека прикладных сервисов (ASL - Application Service Li brary)/54-56/ Данная библиотека разработана компанией PinkRoccade. PinkRoccade ведущая мировая компания в области управления ИТ, участвовавшая в соз дании таких методологий управления, как ITIL (IT Infrastructure Library) и PRINCE2 (Projects in Controlled Environment). PinkRoccade является основ ным автором большей части книг ITIL первой и второй версий. Компания контролирует качество новой, третьей версии ITIL. Как и раньше, компания издает книги, дополняющие ITIL. В 2004 году Getronics приобрела компанию PinkRoccade. В настоящее время Getronics PinkRoccade является мировым лидером в области обучения управлению ИТ, распространяя передовой опыт в ходе тренингов и проектов по внедрению. Данная библиотека поддержива ется фондом ASL (http://www.aslfoundation.org).

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

• приложения стали неотъемлемой частью производства и оборот ным капиталом;

«Framework» в отечественной литературе переводится как «каркасная структура», «рамочный каркас», «стереотип пакета». В UML под фреймворком понимается: «Универсальная архитектура, предоставляющая расширяемый шаблон для приложений внутри предметной области. Фреймворк является отправной точкой для конструирования архитектуры. Обычно элементы фреймворка модифицируются, специализируются и расширяются в процессе подгонки универсальной архитектуры под конкретную проблему» /18/.

PDF created with pdfFactory Pro trial version www.pdffactory.com • значительно возрос объем финансирования управления приложе ниями;

• существенна стоимость управления приложениями;

• приложения воздействую на конкурентоспособность;

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

• потребность в профессионализме;

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

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

• мир «технического» управления или «управления инфраструкту рой» обычно реализован на основе внутреннего или внешнего вычислительного центра или центра ИКТ (в Тюменском государ ственном университете это ЦИТ), осуществляющего управление компьютерами и сетями;

• мир «управления приложениями» осуществляет обслуживание и развитие информационных систем, которые работают на инфра структуре ИКТ;

• мир «системной разработки» занимается разработкой и внедре нием новых приложений (как правило, эта задача осуществляется внешним поставщиком услуг).

Информационно - коммуникационные технологии PDF created with pdfFactory Pro trial version www.pdffactory.com В отличии от «управления приложениями» область «построения сис тем» (системная разработка) имеет много опробованных моделей. Например, методология разработки систем (System Development Methodology – SDM), модель уровней зрелости разработки программного обеспечения (Capability Maturity Model CMM). Построение систем выполняется один раз для прило жения. По этим двум причинам данная область не детализирована в ASL, хо тя при этом определены интерфейсы с обслуживанием и развитием, а «ре конструкция» понимается как одна из форм управления приложениями.

Взаимодействие ИКТ и бизнеса осуществляется, с одной стороны, сер висной командой (service team), которая является единым портом обращения бизнеса к ИКТ (рисунок 5.1), а с другой стороны, Соглашением об уровне услуг (Service Level Agreement - SLA). SLA определяет обязательства по ставщика и обязанности покупателя сервисов. Данное соглашение является отправной точкой, которая гарантирует обслуживание текущих и будущих потребностей клиентов на высоком уровне и по доступной цене.

Структура Библиотеки прикладных сервисов включает процессы в об ласти управления приложениями, их детальное описание и отношения между ними. Детальное описание процессов включает «лучшие методы и ресурсы», такие как: формы, перечень контрольных операций и шаблоны документов.

ASL фреймворк разработан на основе анализа различных областей знаний, связанных с сервисом ИКТ, включая ITIL и CMM.

Процессы в фреймворке ASL можно разделить, отвечая на следующие вопросы:

• Какая точка зрения подхода - «сервис» или «приложение»?

• На каком из уровней рассматриваются процессы (оперативном, тактическом или стратегическом)?

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 5.1 – Схема взаимодействия ролей в области управления при ложениями.

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

Можно выделить две основные точки зрения.

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

восстановление в наименьшие сроки установленных отклоне ний от этого соглашения;

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

превентивная борьба с по ломками;

продвижение новых сервисов;

своевременное реагирование на за Service Level Agreement - соглашение об уровне услуг (сервисов).

PDF created with pdfFactory Pro trial version www.pdffactory.com просы пользователей. Центром этой работы являются сервисы. Сервисы по ставляются и, вместе с управлением инфраструктурой, облегчают использо вание приложений. В терминах стоимости вся эта работа составляет 10 - % полной стоимости управления приложений.

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

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

Для этих двух подходов можно выделить оперативные, тактические и стратегические процессы. Этим обусловлена структура ASL, изображенная на рисунке 5.2.

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

Оперативный уровень.

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 5.2 – Структура ASL.

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

На основании сервисов и приложений на стратегическом уровне выде лены два кластера.

Управление циклом организации (Organization Cycle Management OCM): процессы, которые нацелены на разработку будущего видения орга низации ИКТ сервисов и модернизация стратегии на основе этого видения.

Управление циклом приложений (Applications Cycle Management ACM): процессы, определяющие долгосрочную стратегию для различных приложений в соответствии с долгосрочной политикой организации.

PDF created with pdfFactory Pro trial version www.pdffactory.com Ниже приводится описание перечисленных кластеров.

Процессы обслуживания на оперативном уровне На оперативном уровне для управления информационными системами могут быть идентифицированы следующие области, требующие изучения (зоны внимания - areas of attention):

• идентификация и обслуживание различных объектов сервиса (например, приложение, интерфейс между двумя приложениями, компонент, база данных и т.д.);

• доступность и качество этих объектов;

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

• вопросы, пожелания и недостатки относительно объектов или со гласованного сервиса.

Зоны внимания могут использоваться для определения процессов об служивания (левая сторона рисунка 5.3).

Рисунок 5.3 – Оперативный уровень.

PDF created with pdfFactory Pro trial version www.pdffactory.com Управление инциндентами (Incident control) - процесс, который пре дусматривает урегулирование сервисного вызова или инцидентов. В этом контексте сервисный вызов - вопрос, пожелание, сообщение о поломке и т.д., относительно существующего приложения или приложений. Управление инцидентами обеспечивает, например, процесс единой точки доступа (service desk). Единая точка доступа предоставляет контакт для руководителей функ ционального подразделения и/или для конечных пользователей. Через service desk пользователям предоставляется информация о применении сервисов ИКТ или об их изменении. В процессе управления инцидентами выполнен ные сервисные запросы регистрируются и инициируются действия для их устранения. После устранения проверяется результат выполнения. Структур ный анализ зарегистрированных сервисных запросов дает возможность опре делить действия по усовершенствованию.

Управление конфигурациями (Configuration management) охваты вает процессы, касающиеся регистрации, сохранения и обслуживания ин формации о (версии) компоненте конфигурации, как программном обеспече нии и документации.

Управление доступностью (Availability management) относится к процессам, которые обеспечивают, контролируют и гарантируют доступ ность служб и ИКТ компонентов.

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

Управление непрерывностью (Continuity management) устанавлива ет соотношение мер и средств системы восстановления и резервного копиро вания, гарантирующих непрерывность предоставляемых сервисов, например, в случае бедствий или предотвращения мошенничеств.

Кластер расширения и/или реконструкция обрабатывает на оператив ном уровне ИКТ объекты, такие как, программное обеспечение, документа PDF created with pdfFactory Pro trial version www.pdffactory.com ция и проект. Он основан на использования проектного метода в пределах фреймворка со сценарием повторения. Действия показаны на рисунке 5. (правая сторона):

• анализ влияния: создание условий и плана предполагаемых из менений;

• проект: проведение дальнейшего анализа информации и проек тирования;

• реализация: реализация и/или монтаж измененных объектов;

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

• внедрение: введение измененных объектов в действие, при кото ром основное внимание уделяется конверсии62, тренингу, инст руктажу и передаче этих объектов вместе с рекомендациями для клиентов.

Прежде, чем начать реализацию, необходимо проработать описание проекта и процедуру его инициирования: объяснение требований к проекту, к процессам и к продукту;

график выполнения проекта, его бюджет и органи зацию работ.

На оперативном уровне выделены процессы, отвечающие за связь кла стеров обслуживания и расширение/реконструкция (рисунок 5.3):

Процесс «Управление изменением» связан с процессом, который за прашивает изменение в эксплуатируемом «релизе». При консультации с кли ентом и утверждении анализа влияния, данный процесс приводит к согла шению на изменения, которые будут сделаны в соответствии с графиком, ут вержденной стоимостью и к назначенной дате. На самом деле, управление КОНВЕРСИЯ (от лат. conversio — превращение) — существенное преобразование, изменение условий, замена одних объектов производства другими или одних финансовых инструментов на другие.

PDF created with pdfFactory Pro trial version www.pdffactory.com изменением формирует входящий канал к процессам расширения и реконст рукции.

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

На тактическом уровне в процессах управления рассматриваются сле дующие области:

• время: срок поставки, требуемая производительность и объем ра бот;

• деньги: финансы, включающие общую сумму по предусмотрен ным сервисам;

• качество обеспечиваемых сервисов и методы мониторинга;

• соглашения с клиентами и поставщиками.

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

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

Четыре области, рассматриваемые на тактическом уровне, определяют четыре группы процессов управления (рисунок 5.4).

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 5.4 – Процессы управления.

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

Управление затратами: процессы, связанные с управлением и тари фикацией затрат ИКТ. Выходом управления затратами являются данные по организации процессов, в которых достигнуто оптимальное равновесие ме жду ценой и качеством. Рекомендуется согласовывать процессы с клиента ми.

Управление качеством: процессы управления приложениями, кото рые занимаются качеством процессов, продуктов, сервисов и организации.

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

Управление уровнем сервисов: включает действия, которые опреде ляют более детально требуемые сервисы, устанавливают и контролируют за PDF created with pdfFactory Pro trial version www.pdffactory.com данный уровень обслуживания. Цель управления уровнем сервиса - сделать сервисное обслуживание прозрачным для управления и понимания.

Процессы управления циклом организации (Organization Cycle Man agement - OCM) на стратегическом уровне затрагивают жизненный цикл предусмотренных ИКТ услуг, а также согласование организации ИКТ серви сов. Отношение между клиентской организацией и сервис - провайдером может меняться достаточно динамично, т.к. механизм их взаимодействия весьма многообразен (аутсорсинг, ASP - Application Service Providing, пере дача в частную собственность и т.д.).

В этом кластере определена стратегия, дающая ответ на следующие во просы:

Что поставщик услуг ИКТ должен сделать, чтобы гарантировать тре буемое сервисное обслуживание на долгосрочной основе? Что поставщик ус луг ИКТ должен сделать, чтобы успешно воздействовать на рынок?

На рисунке 5.5 показаны процессы OCM.

Рисунок 5.5 – Стратегический уровень ASL.

PDF created with pdfFactory Pro trial version www.pdffactory.com Определение рынка: на основе анализа рынка, цепочек поставок и развития клиента определяется рыночный сегмент, в котором планируется оказание услуг.

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

Определение предоставляемых услуг: список сервисов, востребо ванных на рынке, и сервисов, предоставляемых поставщиком услуг ИКТ в соответствии с его навыками. Впоследствии, данный список может быть ис пользован при создании политики и стратегии поставщика.

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

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

Все это имеет отношение к требованиям, обеспечению и выпуску.

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

Процессы управления циклом приложений (Applications Cycle Man agement - ACM) концентрируют внимание на информационном обеспечении в будущем и на жизненном цикле объектов в этих условиях. Данные процес сы рассматриваются на двух уровнях: на уровне «приложений» и на уровне «укомплектованного портфеля приложений» поддержки бизнес-процессов.

ACM запрашивает наблюдаемые тенденции в области технологий и бизнес-процессов, как в пределах организации клиента, так и в его окруже PDF created with pdfFactory Pro trial version www.pdffactory.com нии (рассматривается вся цепочка процессов). На рисунке 5.5 показаны про цессы АCM.

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

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

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

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

Внешняя стратегия клиента обеспечивает отражение: развитие цепо чек процессов, результирующие требования;

возможности приложений;

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Библиотека сервиса бизнес-информации (Business Information Service Library – BiSL) /57/ Библиотека разработана компанией PinkRoccade в 2004 г. с целью вос полнения разрыва между бизнесом, инфраструктурой и приложениями. В на стоящее время данная методология поддерживается фондом ASL (http://www.aslfoundation.org).

BiSL разрабатывалась в качестве общественного стандарта для функ ционального и информационного управления. Этот фреймворк содержит ре комендации по построению оптимальной информационной структуры в ор ганизации для процессов и действий. Как показано на рисунке 5.6, библио тека охватывает оперативный, стратегический и тактический (уровень ме неджмента) уровни управления. Данный фреймворк основан на лучших ме тодах ИТ сервис менеджмента, таких как ITIL, ASL.

BiSL, как ITIL и ASL, содержит ряд рекомендаций для предприятия по организации эффективной работы. Эта модель процессов подчеркивает важную роль информационного и функционального управления при связы вании ИКТ и бизнес-процессов.

Внедрение фреймфорка дает возможность получить следующий эф фект:

• затраты на информационное обеспечение организации становятся прозрачными и легко прослеживаются;

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

• более полное использование потенциала поставщиков ИКТ;

• согласованность инвестиций в ИКТ;

• повышение эффективности управления приложениями и техни ческого управления.

В структуре BiSL выделяется семь кластеров процессов (рисунок 5.6):

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 5.6 – Модель фреймворка BISL.

PDF created with pdfFactory Pro trial version www.pdffactory.com Управление использованием.

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

Управление функциональными возможностями.

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

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

Процессы соединения.

Кластеры управления использованием и управления функциональными возможностями нельзя представить себе по отдельности. В процессах соединения выносят решения по вопросам:

• какие изменения должны быть внесены в области информацион ного обеспечения (на рисунке 5.6 верхний треугольник на опера тивном уровне «Управление изменениями»), • как фактически выполняются в пользовательской организации изменения в информационном обеспечении (на рисунке 5.6 ниж ний треугольник на оперативном уровне «Переход»).

Процессы управления (менеджмент).

Эти процессы обеспечивают интегральный контроль кластеров процес сов. Здесь рассматриваются вопросы руководства над действиями управле ния процессов расширения/реконструкции и соединения. Процессы управле ния регулируют действия в терминах: затраты и прибыль, требования кон тракта и сервисного обслуживания, планирование. Центральный вопрос это PDF created with pdfFactory Pro trial version www.pdffactory.com го кластера - процесса: «Как осуществляется информационное обеспече ние?».


Определение информационной стратегии.

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

Определение организационной стратегии информационного обес печения.

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

Процессы соединения на стратегическом уровне.

Процессы в двух предыдущих кластерах нуждаются в координации.

Эту функцию берут на себя процессы в кластере координации информации.

CobiT Задачи контроля для информационных и связанных тех нологий /56, 58-60/ CobiT (Control Objectives for Information and related Technology63), с легкой руки Сергея Гузик (руководителя рабочей группы ISACA.ru) в рус Задачи контроля для информационных и связанных технологий.

Под контролем (Control) понимаются «политики, процедуры, действия и организационные структуры, разработанные с целью обеспечения гарантий того, что бизнес - цели будут достигнуты, а нежелательные события будут предотвращены или обнаружены и исправлены." (Executive Summary, стр. 10) Под задачами контроля (Control Objectives) понимается «изложение желательного результата или цели, которая будет достигнута при осуществлении процедуры контроля в специфической деятельности PDF created with pdfFactory Pro trial version www.pdffactory.com скоязычной литературе переводится, как Контрольные Объекты для Инфор мационных и смежных Технологий64 (КОБИТ) /59/. CobiT издается и под держивается ITGI. Версии 1,2, и 3 из CobiT были изданы в 1996г.,1998 г. и 2000г. Текущая версия CobiT 4.1 предоставляется бесплатно (при условии регистрации на сайте). CobiT - зарегистрированная торговая марка ISACA 65и ITGI66. В России ISACA имеет национальное отделение, сайт которого нахо дится по адресу http://www.isaca-russia.ru.

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

Задачи контроля сгруппированы в 34 процесса, которые часто называ ют «задачи контроля высокого уровня». Процессы, в свою очередь, объеди няются в четыре домена. С другой стороны, задачи контроля детализируются на действия контроля (рисунок 5. 7 ). Продукты CobiT организованы на трех уровнях (рисунок 5.8) для поддержки:

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

• управления бизнесом и ИТ;

ИТ» (Executive Summary, стр. 10). Задачи контроля - "руководство", в котором CobiT описывает, что должно быть достигнуто.

Что дает практически то же звучание в аббревиатуре - (кобит).

Ассоциация аудита и контроля информационных систем образована в 1967 г.;

в настоящее время объединяет около 20 тысяч членов, более чем 100 стран;

Ассоциация координирует деятельность более тыс. аудиторов информационных систем. Штаб квартира ISACA находятся в Иллинойсе.

Институт управления ИТ (ITGI) был основан в 1998 г. (до 2003 г. назывался Information Systems Audit and Control Foundation - ISACF). ITGI некоммерческая организация, выполняющая исследования по направлению ISACA, является разработчиком CobiT.

PDF created with pdfFactory Pro trial version www.pdffactory.com • профессионального управления, обеспечения, контроля и безо пасности.

На рисунке 5. 9 представлены публикации и их целевая аудитория.

Рисунок 5.7 Структура CobiT (указано количество элементов на каж дом уровне).

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

Структура процесса CobiT и его высокоуровневый бизнес - ориентированный подход обеспечивает непрерывное представление ИТ и принятие решений, относительно ИТ.

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 5.8 – Организация продуктов CobiT по уровням.

Реализация CobiT в качестве фреймворка управления ИТ дает возмож ность получить следующие преимущества:

• полное соответствие целям и задачам бизнеса;

• представление работы ИТ структуры, понятное для менеджеров;

• определенные обязанности и долевое участие, в соответствии с процессным подходом;

• общее понимание всех заинтересованных сторон, основанное на едином языке;

• выполнение требований COSO67 для среды ИТ контроля.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Миссия COBIT: исследовать, разрабатывать, публиковать и продвигать авторитетную, выполненную на современном уровне, всемирно признанную структуру контроля за управлением ИТ, с целью ее использования на пред приятиях коммерческими директорами, профессионалами ИТ и обеспечения.

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

Фреймворк CobiT базируется на положении, представленном на ри сунке 5.10. Чтобы предоставить информацию, которая требуется предпри ятию для достижения бизнес - целей, предприятие должно инвестировать и PDF created with pdfFactory Pro trial version www.pdffactory.com менеджмент и контроль ИТ ресурсов, которые используют структурный на бор процессов, обеспечивающий сервисы поставки данной информации.

Управление и контроль информацией лежит в основе фреймворка Co biTb, и позволяет упорядочить бизнес требования.

Рисунок 5.10 – Ориентация на бизнес задачи в CobiT.

Ресурсы ИТ в CobiT описаны пятью составляющими /55/:

• Данные — объекты в широком смысле (то есть внутренние и внешние), структурированные и неструктурированные, а также графика, звук и т.д.

• Приложения — совокупность автоматизированных и выполняе мых вручную процедур.

• Технология — аппаратное обеспечение, программное обеспече ние, операционные системы, системы управления базами данных, сетью и мультимедиа.

• Оборудование — все ресурсы, создающие и поддерживающие информационные технологии.

PDF created with pdfFactory Pro trial version www.pdffactory.com • Люди — персонал, его навыки: умение планировать и организо вывать, комплектовать, обслуживать и контролировать информа ционные системы и услуги.

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

В качестве критериев оценки информации используются /55/:

• Эффективность — актуальность информации соответствующего бизнес-процесса, гарантия своевременного и регулярного полу чения правильной информации.

• Продуктивность — обеспечение доступности информации с по мощью оптимального (наиболее продуктивного и экономичного) использования ресурсов.

• Конфиденциальность — обеспечение защиты информации от не авторизованного ознакомления.

• Целостность — точность, полнота и достоверность информации в соответствии с требованиями бизнеса.

• Пригодность — предоставление информации по требованию бизнес-процессов.

• Согласованность — соответствие законам, правилам и договор ным обязательствам.

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

CobiT определяет ИТ действия общей процессной модели в пределах четырех доменов: планирование и организация, приобретение и реализация, поставка и поддержка, мониторинг и оценка (рисунок 5.11). Домены можно соотнести с традиционными областями ответственности IT: планирование, построение, выполнение и мониторинг.

PDF created with pdfFactory Pro trial version www.pdffactory.com Фреймворк CobiT обеспечивает эталонную модель процесса и общий язык представления и управления действиями ИТ, пригодными для любых предприятий. Соединение операционной модели и общего языка для всех областей бизнеса, использующего информационные технологии, является одним из самых важных и первым шагом к хорошему стилю управления.

Процессная модель служит основой для измерения и контроля производи тельности ИТ;

общению с поставщиками услуг;

интегрировании передового опыта в управлении.


Рисунок 5.11 – Процессная организация CobiT.

Планирование и организация (Plan and Organise - PO) - обеспечивает руководство решением по поставке (AI) и предоставлению услуг (DS).

Приобретение и реализация (Acquire and Implement - AI) – обеспечива ют решения и реализуют их в сервисы.

Поставка и поддержка (Deliver and Support - DS) - получает решения и делает их пригодными для использования конечным пользователем.

Мониторинг и оценка (Monitor and Evaluate - ME) - мониторинг всех процессов с целью информационного обеспечения сопровождения руково дства.

В этих четырех доменах определено 34 ИТ процесса (PO-10;

AI- 7;

DS 13;

ME- 4). В CobiT представлен полный список возможных процессов, кото PDF created with pdfFactory Pro trial version www.pdffactory.com рые могут использоваться для проверки целостности действий и ответствен ности. С другой стороны, не требуется применять все процессы. Процессы могут быть объединены, если это необходимо для данного предприятия. Ка ждый из этих 34 процессов связан с целями бизнеса и ИТ, поддерживающи ми этот бизнес. При этом определены: способы измерения достижения целей, ключевые действия, главный результат и ответственные.

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

Задачи контроля (control objectives) ИТ:

• утверждают административные действия для повышения количе ственных показателей или уменьшения риска;

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

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

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

• выбирать только те, которые возможно применить, • отдать предпочтение тем, которые уже реализованы, • определить способы их осуществления (частота, промежуток, автоматизация и т.д.), • применять те, которые могут использоваться без риска.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Задачи контроля идентифицируются двумя символами, определяющи ми домен (PO, AI, DS, ME), номером процесса и, через точку, номером зада чи контроля68. В дополнение к задачам контроля каждый процесс CobiT имеет универсальные требования контроля (контроль процессов - process control), которые обозначаются PCn (n- номера контроля процесса). Для того, чтобы иметь законченное представление о требованиях контроля, необходи мо рассмотреть PCn вместе с задачами контроля для каждого процесса. К общему контролю процессов относят:

• PC1. Цели и задачи процесса.

• PC2. Владельца процесса.

• PC3. Повторяемость процесса (достигается один и тот же резуль тат процесса, при повторении его выполнения).

• PC4. Роли и их обязанности.

• PC5. Политики, планы и процедуры.

• PC6. Улучшение выполнения процессов.

Кроме того, CobiT предоставляет образец процесса, который использу ется для иллюстрации. Полнота и обязательность выполнения образца не требуется. Образец процесса включает:

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

ответственный – подотчетный - консультирующий - информи рующий (Responsible, Accountable, Consulted and Informed RACI), • цели ключевой деятельности (самые важные вещи, которые нуж но сделать), • метрики (показатели) Например - «PO6.3 Управление политикой ИТ: разработать и соблюдать ряд политик, которые должны поддерживать ИТ стратегию и ряд полисов, чтобы поддержать стратегию ИТ».

PDF created with pdfFactory Pro trial version www.pdffactory.com Система внутренних средств контроля предприятия сталкивается с ин формационными технологиями на трех уровнях.

1. Административный уровень: установлен и утвержден полный подход к управлению предприятием, следовательно, среда кон троля ИТ определена вернем уровнем целей и политики.

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

3. Для поддержки бизнес - процессов ИТ предоставляет общие сер висы, которые используются многими бизнес-процессами. Боль шая часть инфраструктуры предприятия состоит из предостав ляемых общих сервисов (например, сети, базы данных, операци онные системы и хранилища). Контроль всех действий сервисов известен как «Контроль ИТ среды» (IЕ General Controls). Надеж ность контроля ИТ среды влияет на надежность контроля прило жений. Например, плохое управление изменением может стать причиной рисков (случайно или преднамеренно) надежности ав томатизированных проверок целостности.

В качестве примера контроля ИТ среды (или управления ИТ среды) можно привести:

• разработку систем, • управление изменением, • безопасность, • вычислительные операции.

PDF created with pdfFactory Pro trial version www.pdffactory.com Средства управления, внедренные в приложения бизнес-процесса, обычно называются контролем приложений и могут включать:

• полнота, • точность, • валидность, • авторизация, • разделение обязанности.

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

• ответственность бизнеса:

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

• ответственность ИТ:

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

Контроль приложений включает набор задач, которые в CobiT обозна чаются ACn:

AC1. Подготовка и авторизация исходных данных.

AC2. Сбор и ввод исходных данных.

AC3. Проверка на точность, полноту и подлинность.

AC4. Исследование на целостность и достоверность.

AC5. Анализ выхода, согласованность и устранение ошибок.

PDF created with pdfFactory Pro trial version www.pdffactory.com AC6. Аутентификации и целостность транзакций.

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

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

• цели и показатели производительности ИТ процессов, которые выявляют, как процессы выполняются цели бизнеса и ИТ, ис пользуют для измерения внутренние характеристики процесса, основанные на принципах системы взаимосвязанных показате лей69;

• цели деятельности, позволяющие выявить показатели эффектив ности процесса.

Модели зрелости (Maturity models - MM) /58/ Модели зрелости в CobiT предназначены для контроля над ИТ процессами организации. Они базируются на определении уровня развития организации от несуществующего (нулевого) уровня до оптимизированного (пятого) уровня модели зрелости. Этот подход был привнесен в CobiT из Моделей Зрелости, разработанных Институтом проектирования и разработки программного обеспечения (Software Engineering Institute), созданных для оценки уровня зрелости разработки программного обеспечения.

Модели зрелости не подсказывают, как улучшить работу компании и не объясняют, как работать с персоналом. Нет готовых руководств по при менению моделей зрелости. Каждой конкретной компании рекомендуется разработать подобное руководство для своего бизнеса или пригласить сто метод оценки уровня управления, основанный на использовании большого количества критериев PDF created with pdfFactory Pro trial version www.pdffactory.com ронних консультантов для решения этого вопроса. Модели зрелости предна значены для организации эффективного управления. Они определяют ключе вые действия, которые указывают, что надо сделать для достижения требуе мого качества и содержат способы контроля над правильностью выполнения ключевых ИТ-процессов и методы их корректировки.

Используя модели зрелости, разработанные для каждого из 34 процес сов ИТ COBIT, управление может идентифицировать:

• фактические характеристики предприятия (где предприятие на ходится сегодня);

• текущее состояние промышленности (произвести сравнение);

• курс совершенствования предприятия (где предприятие хочет быть);

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

Модель зрелости управления ИТ определяет пять уровней.

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

1 Начальный / Специальный - Есть доказательство того, что пред приятие признает, что проблемы существуют и должны быть решены. Одна ко нет никаких стандартизированных процессов. С другой стороны, есть спе циальные решения, которые имеют тенденцию применяться индивидуально или от случая к случаю. Дезорганизован общий подход в управлении.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 3 Определенных процессов - Процедуры стандартизированы и зареги стрированы, штат обучен. Все это делает обязательным сопровождение про цессов, но маловероятно, что будут обнаружены отклонения в процессах.

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

4 Управляемый и измеримый – Мониторинг управления и измерение согласованы с процедурами, при этом принимаются меры там, где определе ны неэффективные процессы. Процессы находятся в постоянном совершен ствовании и обеспечивают хорошую практику. Автоматизация и инструмен тальные средства используются ограниченно или фрагментировано.

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

Измерение эффективности.

Цели и показатели определены в CobiT на трех уровнях:

• цели и показатели ИТ, определяющие, что ожидает бизнес от ИТ и как они измеряются;

• цели и показатели процесса, определяющие, что процесс ИТ должен поставить для поддержки выполнения ИТ задач, и как они измеряются;

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

Цели определяются сверху вниз: бизнес - цель определяют несколько ИТ целей, каждая из которых определяет цели процессов, которые, в свою очередь, задает несколько действий и их цели.

PDF created with pdfFactory Pro trial version www.pdffactory.com Термины KGI и KPI, используемые в предыдущих версиях CobiT, бы ли заменены на показатели двух типов:

• показатели исхода (Outcome measures OM), ранее ключевые пока затели цели (KGIs), показывают выполнение целей. Они могут быть измерены только после факта выполнения. Их называют «показатели задержки» (lag indicators);

• показатели эффективности (Performance indicators- PI), ранее ключевые показатели эффективности (KPIs), показывают, будут ли выполнены цели. Они могут быть изменены прежде, чем ста нет ясен результат. Они называются «показатели опережения»

(lead indicators).

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

• пригодность требуемой информации для поддержки бизнес - по требностей;

• отсутствие рисков целостности и конфиденциальности;

• эффективность затрат процессов и действий;

• подтверждение надежности, эффективности и согласованности.

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

По этой причине показатели эффективности часто называют драйверами эф фективности, особенно в системах взаимосвязанных показателей. На рисун PDF created with pdfFactory Pro trial version www.pdffactory.com ке 5.12 показана связь между процессами, целями, действиями и показателя ми.

Рисунок - 5.12 Связь между показателями, процессами и целями.

Схема CobiT, объединяющая 34 ИТ - процесса,и учитывающая крите рии информации и ресурсы ИТ на всем протяжении жизненного цикла, пред ставлена на рисунке 5.13.

ITIL – Библиотека описания ИТ инфраструктуры (ITIL V2)/61 64/ В 80-е годы Центральное агентство по вычислительной технике и теле коммуникациям (Central Computer and Telecommunications Agency — CCTA, в настоящее время именуемое Office of Government Commerce — OGC) /65/ британского правительства начало проект по создании унифицированного подхода в области ИТ обслуживания. Результатом усилий явилась Библиоте ка передового опыта организации ИТ (IT Infrastructure Library — ITIL ), кото рая выросла из собрания лучших методов, существовавших в индустрии ИТ услуг.

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 5.13 – Фреймворк CobiT.

PDF created with pdfFactory Pro trial version www.pdffactory.com В настоящее время данный проект претерпел уже третье издание. При этом, OGC поддерживает как вторую, так и третью версию ITIL. ITIL стал стандартом де-факто. Многие ведущие компании мира на основе ITIL разра ботали собственные версии ITSM70. Так, например, HP ITSM Reference Model компании Hewlett-Packard, IT Process Model компании IBM, MOF компании Microsoft.

ITIL это не просто стандарт, это индустрия, поддерживаемая OGC, ко торая включает: публикации книг ITIL;

консалтинг;

система сертификации, проводимая компаниями EXIN и ISE;

обучение;

программные средства;

фо рум по ИТ Сервис-менеджменту itSMF (сайт itSMF- UK http://www.itsmf.org/, российский сайт itSMF http://www.itsmforum.ru/).

ITIL V2 опубликован в 7 книгах, каждая из которых рассматривает во просы отдельной части структурированной процессной основы:

1. Service Support (Поддержка услуг);

2. Service Delivery (Предоставление услуг);

3. Planning to Implement Service Management (Планирование внедрения сервис-менеджмента);

4. Application Management (Управление приложениями);

5. ICT Infrastructure Management (Управление инфраструктурой ин формационных и коммуникационных технологий);

6. Security Management (Управление безопасностью);

7. Software Asset Management (ПО управление активами);

ITSM (IT Service Management)- ИТ Сервис-менеджмента. Используется как синоним термина «управление ИТ-услугами», но, с другой стороны, усиливает его, имея в виду централизованный подход к менеджменту всей ИТ-организации, как современным сервисным подразделением, направленным на предоставление услуг бизнес-подразделениям и являющимся неотъемлемым звеном в производственном процессе /61/ PDF created with pdfFactory Pro trial version www.pdffactory.com 8. The Business Perspective: The IS View on Delivering Services to the Business (Бизнес - перспектива: представление ИС относительно поставки сервисов бизнесу).

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

Рисунок 5.14- Представление элементов библиотеки ITIL V2.

Широко известна книга «ИТ сервис менеджмент. Введение» (белая книга), которая имеет официальную русскую редакцию /61/. В тоже время, книги «Поддержка услуг» (синяя книга) и «Предоставление услуг» (красная книга) считаются центральными. Именно они ассоциируются с сервис - ме неджментом, представленным в ITIL. Ниже будет кратко рассмотрен матери ал именно этих книг.

ITIL базируется на процессно-ориентированном подходе стандарта ИСО 9000. В нем выделяются процессы, которые описаны по общему шаблону:

• введение, которое включает терминологию, специфическую для данного процесса);

PDF created with pdfFactory Pro trial version www.pdffactory.com • цель процесса • описание процесса, с указанием входов и выходов процесса и взаимодействия с другими процессами;

• виды деятельности;

• управление процессом, в котором определены ключевые показа тели успеха (Key Performance Indicators — KPI), критические факторы успеха (Critical Success Factor — CSF), роли и их функ ции;

• затраты и проблемы.

В областях поддержки услуг и предоставления услуг выделяется по пять процессов и одна организационная единица (Service Desk- единая точка доступа).

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

На рисунке 5.15 показаны процессы, описанные в книгах «Service Sup port» и «Service Delivery». Данная методология предполагает, что ИТ депар тамент или коммерческая ИТ организация взаимодействует с бизнесом по одной схеме. Это схема предоставления сервисов на основе предварительной договоренности, которая выражается соглашением об уровне услуг (SLA).

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

Одной из основных целей внедрения ITIL является повышение качест ва71 оказания ИТ услуг. Так как ИТ и бизнес по схеме ITIL дистанцированы, то взаимодействие ИТ и бизнеса является сферой действия управления отно Качество - это совокупность характеристик продукта или услуги, которые- формируют способ ность продукта удовлетворять сформулированные и подразумеваемые потребности (ISО-8402).

PDF created with pdfFactory Pro trial version www.pdffactory.com шениями с заказчиками ИТ-услуг (IT Customer Relationship Management — CRM), которая включает поддержание отношений с заказчиком и координа цию работы с организацией на стратегическом, тактическом и операционном уровнях.

Рисунок 5.15 – Процессы поддержки и предоставления ИТ сервисов и их взаимодействие.



Pages:     | 1 |   ...   | 2 | 3 || 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.