Будь умным!

У вас вопросы?
У нас ответы:) SamZan.net

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

Работа добавлена на сайт samzan.net:


Процессы, функции, роли в процессной модели управления

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

  1. определение и согласование параметров ИТ-сервиса;
  2. обеспечение соответствия фактических параметров ИТ-сервиса достигнутым соглашениям.

Управление процессами предполагает следующие шаги:

  1. определение цели процесса и показателей достижения этой цели (количественных или качественных);
  2. назначение ответственного за процесс, задачей которого является достижение цели процесса;
  3. регламентация процесса в целом и составляющих его работ;
  4. при необходимости - автоматизация процесса посредством инструментальных средств, разработанных в самой организации либо закупленных извне.

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

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

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

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

Рис. 1.3.  Процессы, функции, роли в процессной модели управления

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

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

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

Пути перехода к процессной модели. Общая характеристика ITIL/ITSM. Преимущества ITSM.

Переход к процессной модели можно осуществить двумя путями:

  1. первый состоит в формализации опыта данной организации;
  2. второй предполагает использование передового опыта управления службой ИС, который реализован в типовых моделях бизнес-процессов этой службы.

На сегодняшний день общей методологической основой таких моделей является подход ITIL/ITSM, основанный на сборе и систематизации передовой практики управления службой ИС в течение последних 20 лет.

Модель ITSM, разработанная в рамках проекта ITIL (IT Infrastructure Library - библиотека инфраструктуры информационных технологий, произносится как "айтил"), описывающая процессный подход к предоставлению и поддержке ИТ-услуг. Данная модель получила наибольшую известность в силу того, что предоставление и поддержка ИТ-услуг является первичной задачей ИТ-службы предприятия.

Отражением трансформации роли и места ИТ-службы в структуре предприятий является концепция и модель управления качеством информационных услуг (Information Technology Service Management – ITSM, управление ИТ-услугами)

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

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

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

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

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

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

Состав ITIL. Основные разделы управления ИТ-сервисами

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

Отражением трансформации роли и места ИТ-службы в структуре предприятий является концепция и модель управления качеством информационных услуг (Information Technology Service Management – ITSM, управление ИТ-услугами). Бизнес-процессы сегодня неразделимы с программными приложениями, техническими ресурсами и деятельностью персонала ИТ-служб, поэтому качество работы последних становится важнейшим фактором, определяющим эффективность деятельности предприятия в целом.

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

Модель ITSM, разработанная в рамках проекта ITIL (IT Infrastructure Library - библиотека инфраструктуры информационных технологий, произносится как "айтил"), описывающая процессный подход к предоставлению и поддержке ИТ-услуг. Данная модель получила наибольшую известность в силу того, что предоставление и поддержка ИТ-услуг является первичной задачей ИТ-службы предприятия.

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

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

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

  1. ограничений на использование нет;
  2. материалы модели могут быть использованы полностью или частично;
  3. модель может быть использована в точном соответствии с текстом книг ITIL либо адаптирована пользователем.

Текущая версия библиотеки ITIL включает 7 книг по основным разделам управления ИТ-сервисами:

  1. Service Delivery (предоставление услуг) – содержит описание типов ИТ-услуг, предоставляемых предприятием;
  2. Service Support (поддержка услуг) – представляет собой описание процессов, позволяющих обеспечить пользователям доступ к ИТ-услугам, необходимым для выполнения бизнес-задач;
  3.  Information & Computing Technology Infrastructure Management (управление ИТ-инфраструктурой). В книге представлено общее описание методики организации работы ИТ-службы по управлению ИТ-инфраструктурой компании;
  4. Application Management (управление приложениями) указывает, как обеспечить соответствие программных приложений изменениям в потребностях бизнеса, а также рассматривает общий жизненный цикл приложений, включающий разработку, внедрение и сопровождение;
  5. The Business Perspective (бизнес-перспектива) – рассматривается, как работа ИТ-инфраструктуры может влиять на бизнес компании в целом;
  6. Planning to Implement Service Management (планирование внедрения управления услугами) – посвящена проблемам и задачам планирования, реализации и развития ITSM, необходимым для реализации поставленных целей;
  7. Security Management (управление безопасностью) – посвящена проблемам безопасности. В ней рассматриваются проблемы разграничения доступа к информации и ИТ-сервисам, особенности оценки, управления и противодействия рискам, инциденты, связанные с нарушением безопасности и способы реагирования на них.

Важным элементом инфраструктуры ITIL/ITSM являются так называемые ITSM-форумы. Эти форумы представляют собой сообщества пользователей модели, консультантов, внедряющих модель, и производителей инструментального программного обеспечения. Сообщество, как правило, имеет сайт в сети Интернет (например, ITSM ПОРТАЛ.RU), а также проводит конференции и другие мероприятия, обеспечивающие реальное общение участников. Так российское партнерство "Форум по ИТ Сервис-менеджменту" получило международную аккредитацию ITSMF и стало полноправным членом всемирного сообщества. ITSMF International представляет собой независимое сообщество профессионалов в области управления ИТ-услугами. Оно было создано в Великобритании в 1991 году и занимается пропагандой идей ITSM, разработкой стандартов в этой области и поддержкой обмена опытом в десятках стран мира. На сегодняшний день национальные отделения itSMF действуют уже в 41 стране мира. ITSMF Russia было образовано в 2005 году и на сегодняшний день объединяет около 200 представителей из более чем 45 российских компаний.

Процессы поддержки ИТ-сервисов.  Показатели качества процесса. Функции процесса.

Блок процессов поддержки ИТ-сервисов включает следующие процессы:

  1. управление инцидентами;
  2. управление проблемами;
  3. управление конфигурациями;
  4. управление изменениями;
  5. управление релизами.

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

Показателями качества реализации процесса являются:

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

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

  1. прием запросов пользователей;
  2. регистрация инцидентов;
  3. категоризация инцидентов;
  4. приоритизация инцидентов;
  5. изоляция инцидентов;
  6. эскалация инцидентов;
  7. отслеживание развития инцидента;
  8. разрешение инцидентов;
  9. уведомление клиентов;
  10. закрытие инцидентов.

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

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

  1. анализ тенденций инцидентов;
  2. регистрация проблем;
  3. идентификация корневых причин инцидентов;
  4. отслеживание изменений проблем;
  5. выявление известных ошибок;
  6. управление известными ошибками;
  7. решение проблем;
  8. закрытие проблем.

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

Процесс управления конфигурациями предназначен для оказание помощи в управлении экономическими характеристиками ИТ-сервисов (комбинация требований клиентов, качества и затрат) за счет поддержания логической модели инфраструктуры ИТ и ИТ-сервисов, а также предоставление информации о них другим бизнес-процессам. Это реализуется путем идентификации, мониторинга, контроллинга и обеспечения информации о конфигурационных единицах (CI – Configuration Item) и их версиях. Конфигурационные единицы описывают системные компоненты с их конфигурационными атрибутами.

Процесс Управление конфигурациями отвечает за поддержание информации о взаимоотношениях между CI и за стандартизацию CI, мониторинг информации о статусе CI, их местоположении и всех изменениях CI. Информация о CI хранится в базе данных конфигурационных единиц (Configuration Management Data Base – CMDB). База данных управления конфигурациями представляет собой репозиторий метаданных, описывающий элементы конфигурации, их взаимосвязи и атрибуты. Элементы конфигурации представляют информационные компоненты, являющиеся объектами или субъектами процесса управления конфигурациями:

  1. материальными сущностями (серверная стойка, компьютер, маршрутизатор, модем, сегмент линии связи);
  2. системными или прикладными программными продуктами и компонентами;
  3. реализациями баз данных;
  4. файлами;
  5. потоками данных;
  6. нормативными или техническими документами;
  7. логическими или виртуальными сущностями (виртуальный сервер, серверный кластер, пул дисковой памяти, группа устройств).

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

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

При спецификации процесса важными понятиями являются:

  1. сфера охвата;
  2. глубина детализации;
  3. контроль;
  4. мониторинг статуса;
  5. верификация.

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

Глубина детализации (Level of Detail) – важный аспект, определяющий в дальнейшем отношения между CI. Отношения, как правило, рассматриваются физические и логические.

Физические отношения:

  1. родители - дети;
  2. соединенная.

Логические отношения:

  1. копия;
  2. "использует", когда одна единица использует другую. Например, программа использует сервер.

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

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

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

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

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

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

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

  1. обрабатывает запросы на изменения;
  2. оценивает последствия изменений;
  3. утверждает изменения;
  4. разрабатывает график проведения изменений, включая восстановление при сбое;
  5. устанавливает процедуру обработки запроса на изменение;
  6. устанавливает категории и приоритеты изменений;
  7. управляет проектами изменений;
  8. организует работу комитета по оценке изменений;
  9. осуществляет постоянное улучшение процесса.

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

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

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

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

Процесс управления релизами состоит из трёх этапов:

  1.  разработка;
  2.  тестирование;
  3.  распространение и внедрение.

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

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

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

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

  1.  планирование релиза;
  2.  проектирование, разработка, тестирование и конфигурирование релиза;
  3.  подписание релиза в развертывание;
  4.  подготовка релиза и обучение пользователей;
  5.  аудит оборудования и ПО до начала внедрения изменений и по завершении такового;
  6.  размещение эталонных копий ПО в DSL;
  7.  установка нового или усовершенствованного оборудования и ПО;
  8.  постоянное улучшение процесса.

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

По масштабу релизы подразделяются на три вида:

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

По способу реализации релизы подразделяются также на три вида:

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

Особой сферой ответственности процесса управления релизами является библиотека эталонного ПО (Definitive Software Library - DSL). Все позиции DSL отражаются как записи CMDB. Эта библиотека - физическое хранилище протестированных и подготовленных к распространению копий разработанного и покупного ПО, лицензий на последнее, а также пользовательской и эксплуатационной документации. Информация о копиях ПО, хранящихся в DSL, ведется в базе данных позиций конфигурации. Наличие такой библиотеки играет важную роль в процессе управления релизами, особенно на этапе распространения и установки ПО.

Функции процесса управления релизами таковы:

  1.  планирование релиза;
  2.  проектирование, разработка, тестирование и конфигурирование релиза;
  3.  подписание релиза в развертывание;
  4.  подготовка релиза и обучение пользователей;
  5.  аудит оборудования и ПО до начала внедрения изменений и по завершении такового;
  6.  размещение эталонных копий ПО в DSL;
  7.  установка нового или усовершенствованного оборудования и ПО;
  8.  постоянное улучшение процесса.

Соглашение об уровне сервиса (Service Level Agreement – SLA). Разделы входящие в SLA.

Основным документом, регламентирующим взаимоотношения ИС-службы и бизнес-подразделений предприятия, является соглашение об уровне сервиса (Service Level Agreement – SLA). В данном документе дается качественное и количественное описание ИТ-сервисов, как с точки зрения службы ИС, так и с точки зрения бизнес-подразделений.

Соглашение об уровне сервиса определяет взаимные ответственности поставщика ИТ-сервиса и пользователей этого сервиса.

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

  1. определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения;
  2. доступность ИТ-сервиса;
  3. число и размещение пользователей и/или оборудования, использующих данный ИТ-сервис;
  4. описание процедуры отчетов о проблемах;
  5. описание процедуры запросов на изменение.

Спецификации целевых уровней качества сервиса, включая:

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

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

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

  1. имя сервиса;
  2. ссылки на связанные сервисы;
  3. описание сервисов, функций, границ предоставления сервисов, профилей пользователей;
  4. поддерживаемые платформы или инфраструктуры;
  5. характеристики доступности, производительности;
  6. процедуры поддержки;
  7. метрики;
  8. процедуры мониторинга.

В операционной части приводят:

  1. имя владельца сервиса;
  2. профиль клиента;
  3. зависимости от других сервисов;
  4. модель Operations Level Agreement (OLA);
  5. детальная информация о технической инфраструктуре, необходимой для обеспечения сервиса;
  6. единицы инфраструктуры, рассматриваемые как активы;
  7. план поддержания целостности, улучшения качества сервисов, развития возможностей;
  8. результаты аудита;
  9. информация о ценах.

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




1. Формирование математической модели корпуса теплохода-площадки в программе FstShip6
2. Тема- Історичний портрет Івана Мазепи Виконав- Студент КІТ 43А Стальчук В1
3. тема человек художественный образ человек природа НАЗНАЧЕНИЕ ТЕСТА Методика предназначена для отбора
4. Первые декреты Советской власти
5. формирование используется как обобщенное включающее в себя все виды детских организаций объединений дви
6. тематика Теореми Ролля Лагранжа Коші
7.  Сложнорефлекторная фаза
8. странице http---www.bmompress
9. ccurcy is one of the mjor items in judging control system
10. Реферат- Битва при Бородино
11. реферат дисертації на здобуття наукового ступеня кандидата технічних наук Кіровоград ~ 1999 Дисе
12. Реферат- Техногенное развитие и техносферизация планеты
13. Восстановленная спина Этот семинар позволит вам восстановить здоровье вашего позвоночника и суставов
14. Практикум - В.А.Гончаров
15. Black label society
16. реферату- Енеоліт на території УкраїниРозділ- Історія України Енеоліт на території України Наприкінці V
17. Тема- УЧЕТ ДЕНЕЖНЫХ СРЕДСТВ И РАСЧЕТОВ НА ПРИМЕРЕ ООО МОДНЫЙ ДОМ Студентки Кирилловой Н
18. Русская рукописная книга XI-XV веков
19. Тема- Хирургический инструментарий
20. ТЕМА УКРАЇНИ ТА ОСНОВНІ НАПРЯМИ ЇЇ РОЗВИТКУ Спеціальність 08

Материалы собраны группой SamZan и находятся в свободном доступе