ИТ Сервис Менеджмент

ITSM (IT Service Management, управление IT услугами) — подмножество библиотеки ITIL получила наибольшую известность в силу того, что предоставление и поддержка IT-услуг является первичной задачей IT-подразделений и специализированных IT-компаний, которые зачастую сталкиваются с недостаточной зрелостью данных процессов, необходимостью измерять и контролировать качество услуг.

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

Как наиболее известная часть ITIL в целом. Однако

Содержание

В настоящее время существует несколько версий библиотеки ITIL. Под ITSM версии 2 подразумеваются две книги ITIL: «Предоставление услуг» («Service Delivery») и «Поддержка услуг» («Service Support»), состоящие из следующих частей (глав):

• Поддержка услуг (Service Support)
  1. Служба Service Desk (Service Desk)
  2. Процесс управления инцидентами (Incident Management)
  3. Процесс управления проблемами (Problem Management)
  4. Процесс управления конфигурациями (Configuration Management)
  5. Процесс управления изменениями (Change Management)
  6. Процесс управления релизами (Release Management)
• Предоставление услуг (Service Delivery)
  1. Процесс управления уровнем услуг (Service Level Management)
  2. Процесс управления финансами (Financial Management for IT Services)
  3. Процесс управления мощностью (Capacity Management)
  4. Процесс управления непрерывностью (IT Service Continuity Management)
  5. Процесс управления доступностью (Availability Management)

Под ITSM версии 3 подразумеваются пять книг ITIL: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement, состоящие из:

• Service Strategy
  1. Delivery Model (Модель предоставления услуг)
  2. Service Model (Модель услуги)
  3. Service Portfolio Management (Управление портфелем услуг)
  4. Demand management (Управление требованиями)
  5. Financial Management (Управление финансами)
• Service Design
  1. Service Portfolio (Портфель услуг)
  2. Service Catalogue (Каталог услуг)
  3. Service Catalogue Management (Управление Каталогом услуг)
  4. Service Level Management (Управление уровнем услуг)
  5. Supplier Management (Управление поставщиками)
  6. Availability Management (Управление доступностью)
  7. Information Security Management (Управление безопасностью информации)
  8. Capacity Management (Управление мощностями)
  9. IT Service Continuity Management (Управление непрерывностью)
• Service Transition
  1. V-модель
  2. Knowledge Management (Управление знаниями)
  3. Модель DIKW
  4. Service Knowledge Management System, SKMS (Система управления знаниями)
  5. Change Management (Управление изменениями)
  6. 7R управления изменениями
  7. Управления изменениями и управление проектами
  8. Service Asset and Configuration Management (Управление активами и конфигурациями)
  9. Configuration Item (Конфигурационная единица)
  10. Configuration Management System (CMS)
  11. Release and Deployment Management (Управление релизами и развёртыванием)
  12. Definitive Media Library (DML)
• Service Operation. Функции.
  1. Функция Service Desk
  2. Функция Technical Management
  3. Функция Application Management
  4. Функция IT Operations Management
  5. Service Operation. Процессы.
  6. Event management (Управление событиями)
  7. Incident Management (Управление инцидентами)
  8. Request Fulfillment (Выполнение запросов на обслуживание)
  9. Problem Management (Управление проблемами)
  10. Access Management (Управление доступом)
• Continual Service Improvement (Непрерывное улучшение качества услуг)

Далее идет краткое описание ITIL версии 2.

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

Служба Service Desk

Неотъемлемой частью процессной организации по ITSM является Service Desk — подразделение (в терминологии ITIL «функция»), обеспечивающее единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов. Зачастую внедрение процессного подхода к предоставлению услуг начинается именно с внедрения Service Desk.

Процесс управления инцидентами (Incident Management, INC)

Цель процесса управления инцидентами — скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса.

ОПРЕДЕЛЕНИЯ

Инцидент (incident)

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

Запрос на обслуживание (service request)

каждый INC, не являющийся сбоем в ИТ инфраструктуре (запрос на информацию, сброс забытого пароля)

Обходное решение (work-around)

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

Эскалация

механизм, служащий своевременному разрешению INC с помощью привлечения дополнительных знаний (функциональная эскалация) или полномочий (иерархическая эскалация). Цель — решить INC в срок указанный в SLA.

Приоритет (priority)

основанная на степени влияния и срочности последовательность решения INC

ВИДЫ ДЕЯТЕЛЬНОСТИ

Обнаружение и регистрация

сохранение информации об INC; оповещение специалиста; инициирование процедур обработки запросов на обслуживание

Классификация и начальная поддержка

классификация; сопоставление с проблемами и известными ошибками; информирование специалистов Упр.проблемами; определение степени влияния, срочности, приоритета; оценка информации из CMDB; предоставление начальной поддержки

Расследование и диагностика

оценка информации об INC; сбор и анализ доп.информации; поиск решения

Решение и восстановление

решении; подача RFC; выполнение действий по восстановлению

Закрытие

подтверждение удовлетворенности пользователя/ заявителя; присвоение кода закрытия

Владение, мониторинг, коммуникации

мониторинг INC; эскалация; оповещение пользователя

Отчетность

ВХОДЫ

• Инциденты
• Сведения об инфраструктуре (CMDB)
• Сведения о проблемах и известных ошибках
• Сведения о способах решения инцидентов
• Ответы на поданные RFC

ВЫХОДЫ

• Запросы на изменения
• Сообщения о некорректности данных в CMDB
• Решенные и закрытые инциденты
• Записи об инцидентах
• Оповещения
• Отчеты

РОЛИ

Владелец процесса

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

Менеджер процесса

организует взаимодействие участников; планирует и реализует мероприятия по развитию процесса; обеспечивает актуальность процессной документации и ее формирование; участвует в иерархической эскалации

Специалисты 1 и пр. линий поддержки

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА

• Пристальное внимание к управлению процессом
• Реалистичные цели и контроль их достижения
• Актуальная CMDB
• База знаний по известным ошибкам и проблемам
• Автоматизация настроена в соответствии с требованиями процесса
• Четкие целевые показатели поддержки, согласованные с пользователями в рамках процесса SLM
• Наличие эффективных инструментов диагностики
• Наличие резервов для быстрого применения обходных решений

МЕТРИКИ

• Общее количество INC
• Среднее фактическое время, затраченное на разрешение INC/ поиск обходного решения
• Процент INC, обработанных в рамках согласованного времени реакции (SLA)
• Средние затраты на INC
• Процент INC, закрытых SD без передачи на др.уровни поддержки
• Количество и процент INC, разрешенных удаленно, без посещения

ПРЕИМУЩЕСТВА

Для бизнеса:

• Снижение негативного влияния INC на бизнес благодаря своевременному их разрешению
• Доступность бизнес ориентированной информации о выполнении SLA

Для ИТ-организации:

• Мониторинг соответствия предоставляемого уровня сервиса уровню, определенному в SLA
• Более рациональное использование персонала
• Снижение числа потерянных и некорректно обработанных INC и RFC
• Выявление некорректных данных в CMDB
• Повышение удовлетворенности заказчиков и пользователей

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

• Некому управлять и производить эскалацию INC, INC могут стать более трудными для разрешения
• Специалисты SD постоянно отрываются на выполнение других задач
• Бизнес-персонал отрывается от основных функций, так как коллеги обращаются к др.др. за советами
• Частое расследование INC с самого начала из-за отсутствия готовых решений
• Нехватка согласованной управленческой информации
• Потерянные, неправильно или плохо управляемые INC

РИСКИ

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

Процесс управления проблемами (Problem Management, PRB)

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

ОПРЕДЕЛЕНИЯ

Проблема (problem)

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

Известная ошибка (known error)

PRB, которая успешно диагностирована и для которой определено обходное решение

ВИДЫ ДЕЯТЕЛЬНОСТИ

Контроль проблем

идентификация и запись PRB; классификация PRB; расследование и диагностика PRB

Контроль ошибок

оценка ошибок; запись о ходе разрешения ошибок (оформление RFC); закрытие ошибок; мониторинг PRB и прогресса разрешения ошибок

Проактивное выявление PRB

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

Обзор значительных PRB

что было сделано правильно/ неправильно

Отчетность

ВХОДЫ

• Инцидент (INC)
• Сведения об инфраструктуре (CMDB)
• Сведения об обходных решениях INC (work-around)

ВЫХОДЫ

• Записи о PRB и известных ошибках
• Обходные решения
• RFC
• Решенные PRB
• Отчеты

РОЛИ

Менеджер проблем

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

Поддержка решения проблем

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

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА

• Пристальное внимание к управлению процессом
• Реалистичные цели и контроль их достижения
• Актуальная CMDB
• База знаний по известным ошибкам и проблемам
• Автоматизация настроена в соответствии с требованиями процесса
• Эффективный процесс управления INC, особенно в части классификации и привязки
• Эффективное взаимодействие c процессом управления INC
• Грамотное использование аналитических способностей персонала, выделение ресурсов

МЕТРИКИ

• Количество оформленных RFC и их влияние на доступность и надежность предоставляемых услуг
• Объем времени по типам PRB, потраченный на расследование и диагностику
• Количество и влияние INC, возникающих до закрытия корневой проблемы /подтверждения известной ошибки
• Количество PRB и ошибок по статусу/ услуге/ влиянию/ категории
• Общее фактическое время, потраченное на закрытие PRB

ПРЕИМУЩЕСТВА

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

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

• SD работает только по принципу реагирования и устраняет PRB когда предоставление услуги Заказчику — прервано
• Пользователи ИТ сталкиваются с повторяющимися INC и теряют доверие к качеству SD
• SD становиться не эффективной, так как требуется разрешение повторяющихся INC и структурные решения не внедряются

РИСКИ

• Отсутствие поддержки у руководства, нехватка ресурсов
• Отсутствие хорошо налаженного процесса управления INC — отсутствие подробных исторических данных по INC
• Отсутствие деятельности по улучшению процесса и обновлению процессной документации
• Неспособность связать записи об INC с записями PRB/ ошибок — снижает точность определения влияние INC и PRB на бизнес
• Нечеткое распределение обязанностей
• Неадекватная система автоматизации
• Сопротивление изменениям

Процесс управления конфигурациями (Configuration Management, CFG)

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

ОПРЕДЕЛЕНИЯ

Конфигурационная единица (сonfiguration item)

элемент инфраструктуры или объект, связанный с элементами инфраструктуры (например, RFC), который находится/ должен находиться под контролем процесса упр.конфигурациями

Конфигурационная база данных (Configuration Management Database)

база данных, содержащая все необходимые сведения по всем CI и о связях между ними

Базисная конфигурация (сonfiguration baseline)

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

Управление активами

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

Управление конфигурациями

процесс хранения технической информации о CI и связях между ними

ВИДЫ ДЕЯТЕЛЬНОСТИ

Планирование

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

Идентификация

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

Контроль CI

регистрация новых CI; обновление CI по факту выполнения изменений; обновление RFC (связанные CI, детали реализации); обновление данных CMDB для устранения выявленных расхождений; лицензионный контроль; архивация CI при удалении/ списании активов

Учет статуса конфигураций

отчетность по всем текущим и историческим данным каждой CI в течении всего ее жизненного цикла

Верификация и аудит

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

РОЛИ

Менеджер конфигураций

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

Библиотекарь

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

Координатор конфигураций

Специалист по учету ИТ-активов

ПРЕИМУЩЕСТВА

• Предоставление точной информации об CI и соотв-й документации (поддержка др. процессов)
• Контроль ценных CI
• Содействие в финансовом планировании и планировании расходов (ожидаемые затраты)
• Доступность информации о произведенных CHG в ПО
• Участие в планировании действий при ЧС
• Поддержка и улучшение Упр.релизами
• Улучшение безопасности посредством контроля за используемыми версиями CI
• Предоставление возможности уменьшить использование несанкционированного ПО
• Предоставление возможности безопасно, продуктивно и эффективно анализировать влияние и планировать CHG
• Предоставление Упр.проблемами данных о тенденциях

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА

• Пристальное внимание к управлению процессом
• Реалистичные цели и контроль их достижения
• Актуальная CMDB
• Автоматизация настроена в соответствии с требованиями процесса
• Наличие эффективных инструментов диагностики

МЕТРИКИ

• Количество расхождений, выявленных за период
• Количество INC и PRB, связанных с некорректно отработанными CHG
• Количество RFC, которые не выполнены из-за плохой оценки влияния, некорректных данных в CMDB или плохого контроля версий
• Ср.время согласования/ реализации CHG
• Количество «лишних» лицензий в разбивке по площадкам
• Количество обнаруженных незарегистрированных CI

РИСКИ

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

Процесс управления изменениями (Change Management, CHG)

Цель процесса управления изменениями — обеспечение внесения изменений в IT-инфраструктуру в соответствии со стандартизованными процедурами, для эффективного проведения изменений и минимизации рисков внесения изменений на функционирование инфраструктуры.

ОПРЕДЕЛЕНИЯ

Изменение

добавление, модификация или удаление компонентов инфраструктуры, влияющих на ИТ-сервисы

Запись об изменении (change record, request for change)

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

Полномочные лица (change authority)

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

Стандартное изменение

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

Модель изменения (change model)

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

Комитет по изменениям (change advisory board, CAB)

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

Перспективный план изменений (forward schedule of change — FSC)

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

Прогнозируемая доступность сервисов (Projected service availability, PSA)

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

Оценка результатов внедрения (Post implementation review, PIR)

этап в процессе управления изменениями на котором оценивается результат изменений. Если изменения прошли успешно, RFC, отвечающий за это изменения — закрывается

ВИДЫ ДЕЯТЕЛЬНОСТИ

Регистрация и фильтрация запросов на CHG

Классификация CHG

Оценка влияния и ресурсов (приоритет и степень воздействия)

Согласование и одобрение CHG

Планирование CHG

Построение, тестирование и реализация

Оценка CHG (подтверждение итогов)

ВХОДЫ

• RFC
• CMDB
• FSC

ВЫХОДЫ

• FSC
• RFC
• Протоколы собраний САВ и его действия
• Отчеты

РОЛИ

Менеджер по изменениям

первичная оценка и фильтрация RFC, первичная классификация; организация работы CAB; авторизация принятых CAB решений; публикация FSC /PSA; координация и контроль CHG, организация взаимодействия с вовлеченными сторонами; обновление журнала CHG; оценка отложенных/ задержанных RFC; анализ RFC, выявление тенденций, анализ рисков; закрытие RFC; отчетность о работе процесса

Участник САВ

оценка поступающих для согласования RFC (оценка влияния, стоимости, ресурсов); участие в САВ и САВ/EC; обеспечение доступности для срочного согласования CHG; предоставление рекомендаций по проведению CHG

Координатор изменений

Аналитик изменений

ПРЕИМУЩЕСТВА

• Улучшение согласованности ИТ-услуг и требований бизнеса
• Улучшение оценки рисков
• Уменьшение отрицательного влияния CHG на качество услуг и на SLA
• Более точные оценки затрат на предполагаемые CHG
• Уменьшение количества CHG, которые требуют отката
• Улучшение Управления проблемами и Управления доступностью — из-за дополнительной информации об CHG
• Повышение продуктивности работы пользователей — из-за уменьшения простоев
• Обеспечение возможности обрабатывать большие объемы CHG
• Улучшение мнения бизнеса об ИТ- из-за улучшения качества услуг

МЕТРИКИ

• Количество INC, которые возникли в результате внедрения CHG
• Количество INC, которые привели к CHG
• Количество откатов CHG
• Количество успешно проведенных CHG
• Количество RFC
• Количество отклоненных RFC

РИСКИ

• Отсутствие поддержки у руководства, нехватка ресурсов
• Распределение ответственности по управлению инфраструктурой неоднозначно — задержки в согласовании
• Отсутствие управления конфигурациями — оценка и планирование затруднены
• Процесс усложнен — процедуры не выполняются
• Некорректные данные о конфигурации — ошибки в оценке и планировании
• Сложная распределенная инфраструктура — затрудняет единое управление
• Процедуры отката не разработаны/неэффективны
• Обработка CHG вручную затрудняет и замедляет управление
• Процесс не справляется с обработкой срочных изменений

Процесс управления релизами (Release Management, REL)

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

ОПРЕДЕЛЕНИЕ

Релиз (release)

набор новых и/ или измененных CI, которые совместно тестируются и вводятся в эксплуатацию

Библиотека эталонного ПО (definitive software library, DSL)

защищенное хранилище дистрибутивов протестированных и авторизованных версий ПО

Единица релиза (release unit)

набор компонентов ИТ сервиса, которые обычно внедряются вместе

ВИДЫ ДЕЯТЕЛЬНОСТИ

Планирование REL

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

Проектирование сборка и конфигурация REL

Приемка REL (тестирование)

Планирование развертывания

подготовка плана ресурсов; списки CI для инсталляции/ списания, включая сведения о методе устранения всего лишнего АО и ПО; документирование плана действий для каждой площадки; формирование описания REL и коммуникаций с конечным пользователем; планирование коммуникаций; разработка плана закупок; приобретение АО и ПО; составление графика встреч с персоналом вовлеченным в REL

Коммуникации, подготовка и обучение

Распространение и инсталляция

ВХОДЫ

• Авторизованные RFC
• Политика упр.релизами
• Результаты работы САВ

РОЛИ

Менеджер процесса упр.релизами

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

Менеджер по тестированию

Координатор упр.релизами

Менеджер DSL\DHS

ПРЕИМУЩЕСТВА

• Увеличение доли успешных REL АО и ПО — увеличение качества услуг
• Минимизация прерываний в предоставлении услуг бизнесу
• Гарантирование того, что эксплуатирующиеся АО и ПО обладают известным уровнем качества
• Стабильность тестовой среды и среды эксплуатации (сокращение ошибок)
• Возможность сборки и контроля ПО, используемого в удаленных площадках, из центра
• Экономия средств, отведенных на поддержку за счет унификации АО и ПО
• Уменьшение вероятности появления и использования нелегальных версий ПО — аудит лицензий
• Уменьшение риска незамеченного появления вирусов и прочего подобного ПО
• Уменьшение времени для REL

МЕТРИКИ

• Доля REL, завершенных в срок и в бюджет
• Доля REL, по которым применен план отката
• Количество INC, вызванных ошибками при развертывании релизов (за временной период)
• Доля REL, внедренных без тестирования
• Число некорректных описаний REL в CMDB
• Число расхождений в DSL\DHL

РИСКИ

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

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

Управление уровнем услуг (Service Level Management, SLM)

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

ОПРЕДЕЛЕНИЯ

Требование к уровню услуг (Service level requirements, SLR)

детальное описание потребностей заказчика. Может использоваться для разработки SLA

Каталог услуг (Service catalog)

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

Соглашение об уровне услуг (Service level agreement, SLA)

соглашение между заказчиком и поставщиком ИТ-услуг, содержащее описание услуг и их метрик

Программа улучшения сервиса (Service improvement program, SIP)

проект, в рамках которого определяются виды деятельности по улучшению качества ИТ-сервисов и их этапы

План обеспечения качества услуг (Service quality plan, SQP)

документ в котором определены цели улучшения для каждого процесса. Если SLA определяет «что» мы будем предоставлять, то SQP определяет «как» мы будем это предоставлять

Операционное соглашение об уровне услуг (Operational level agreement, OLA)

соглашение с внутренним ИТ- подразделением, в котором конкретизируется предоставление определенных элементов сервисов

Внешний договор (Underpinning contract, UC)

договор с внешним поставщиком, который определяет предоставление услуг

Качество

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

ИТ сервис

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

ВИДЫ ДЕЯТЕЛЬНОСТИ

Составление каталога услуг

Сбор требований к уровню услуг

Подготовка и согласование соглашения об уровне услуг

Составление и согласование соглашения об уровне услуг

Составление программы улучшения сервиса

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

Аудит и отчетность

ВХОДЫ

• Требования к уровню услуг (Service Level Requirements — SLR)

ВЫХОДЫ

• Каталог услуг (Service Catalog)
• Соглашение об уровне услуг(Service Level Agreement — SLA)
• Программа улучшения сервиса (Service Imrovement — SIP)
• План обеспечения качества услуг (Service Quality Plan — SQP)
• Операционное соглашение об уровне услуг (Operational Level Agreement — OLA)
• Внешний договор (Underpinning contract — UC)

РОЛИ

Менеджер уровня обслуживания

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

МЕТРИКИ

• Число случаев нарушений SLA(инциденты)
• Число случаев нарушений SLA по вине внешних подрядчиков, осуществляющих поддержку (инциденты)
• Процент SLA требующего изменения(% SLA)
• Затраты на предоставление услуг (затраты)
• Степень удовлетворенности клиентов (удовлетворенность)

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

РИСКИ

Управление финансами (Financial Management for IT Services, FIN)

Цель процесса — обеспечение рентабельного распоряжения активами и ресурсами ИТ, необходимой для эффективного предоставления ИТ-услуг.

ОПРЕДЕЛЕНИЯ

Составление бюджета (Budgeting)

прогнозирование затрат и контроль расходов

Бухгалтерский учет (Accounting)

мониторинг расходования финансовых средств ИТ-организаций

Выставление счетов (Charging)

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

Прямые затраты (Direct costs)

затраты связанные исключительно с какой-либо ИТ услугой

Косвенные затраты (Indirect costs)

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

Постоянные затраты (Fixed costs)

не зависят от объема предоставляемых услуг (инвестиции в ПО и АО, строительство)

Переменные затраты (Variable costs)

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

Капитальные затраты (Capital costs)

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

Операционные затраты (Operational costs)

ежедневные затраты, не связанные с МТР (напр., стоимость лицензий, страховые взносы)

Затраты на оборудование (Equipment cost unit, ECU)

затраты на аппаратное обеспечение

Затраты на ПО (Software cost unit, SCU)

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

Организационные затраты (Organization cost unit, OCU)

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

Затраты на размещение (Accommodation cost unit, ACU)

прямые и косвенные затраты, связанные с размещением (офис, серверные комнаты)

Трансферные затраты (Transfer cost unit, TCU)

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

Учет затрат (Cost accounting, CA)

затраты, связанные с деятельностью самого процесса УФ

ВИДЫ ДЕЯТЕЛЬНОСТИ

Обеспечение контроля ИТ-затрат

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

Предоставление финансовой информации инициаторам установки программных продуктов/конфигураций

Контроль использования ИТ-активов для обеспечения максимального возврата инвестиций в ИТ

Распределение по статьям бюджета расходов по ИТ

ВХОДЫ

• Типы затрат

ВЫХОДЫ

• Бюджет
• Обоснование расходов
• Учет затрат

РОЛИ

Руководитель ИТ

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

МЕТРИКИ

• Степень достоверности (в процентах) последнего финансового прогноза (% затрат)
• Совокупная стоимость владения (Total Cost of Ownership — TCO) ИТ (стоимость)

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

РИСКИ

Управление мощностью (Capacity Management, CAP)

Цель процесса — обеспечить, чтобы мощность ИТ всегда была обоснованной с точки зрения затрат и соответствовала как текущим, так и известным будущим потребностям бизнеса.

ОПРЕДЕЛЕНИЯ

Управление производительностью (Performance management)

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

Планирование мощностей (Capacity planning)

разработка Плана по мощностям на основе БД мощностей, анализ текущей ситуации и прогнозирование будущего использования ИТ-инфраструктуры

Масштабирование приложений (Application sizing)

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

Моделирование (Modeling)

определение требующихся мощностей

План мощностей (Capacity plan)

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

База данных мощностей (Capacity Database, CDB)

база данных содержащая сведения о емкости элементов ИТ инфраструктуры. Может входить в состав CMDB

ВИДЫ ДЕЯТЕЛЬНОСТИ

Мониторинг

Формирования в централизованном хранилище данных о производительности ИТ-ресурсов для анализа тенденций, изменений потребностей и планирования инвестиций в ИТ-инфраструктуру

Согласование требований

Согласования достижимого качества предоставления ИТ-услуг с учетом возможностей ИТ-ресурсов

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

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

Оптимизация

Централизации и автоматизации динамического перераспределения ИТ-мощностей

Устранения избытка или нехватки ИТ-ресурсов;

Оценка

Оценки возможностей виртуализации ИТ-ресурсов

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

на основе оперативных или прогнозируемых потребностей в производительности ИТ-ресурсов для обеспечения необходимого уровня бизнес-услуг

ВХОДЫ

• Уровни Сервиса
• Бизнес-план
• Бизнес- стратегия
• Требования бизнеса
• План проектов
• Финансовый план
• Бюджет

ВЫХОДЫ

• Анализ эффективности (Effectiveness)
• План мощностей (Capacity plan)
• База данных мощностей (Capacity Database, CDB)
• Отчеты о мощностях
• Аудиторские отчеты
• Рекомендации по уровню сервиса

РОЛИ

Менеджер по мощностям

организует исполнение процесса; разрабатывает и поддерживает план по мощностям, актуализирует базу данных мощностей (CDB)

ПРЕИМУЩЕСТВА

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА

МЕТРИКИ

• Процент избыточной производительности ИТ(% нагрузки)
• Число нарушений SLA, из-за недостаточной производительности (нарушения SLA)
• Процент CI, для которых ведется мониторинг производительности (% CI)
• Стоимость разработки плана развития мощностей (расходы)

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

РИСКИ

Управление непрерывностью (IT Service Continuity Management, ITSCM)

Цель процесса — управление непрерывностью предоставления услуг, поддерживать общий процесс управления непрерывностью бизнеса, обеспечивая восстановление работоспособности необходимого оборудования и служб ИТ(включая компьютерные системы, сети, приложения, телекоммуникации, техническую поддержку и службу Service Desk) в требуемые для бизнеса и оговоренные с ним сроки.

ОПРЕДЕЛЕНИЯ

Чрезвычайная ситуация

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

Процесс управления непрерывностью бизнеса (Business continuity management, BCM)

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

План обеспечения непрерывности работы (Contingency plan)

Анализ воздействия на бизнес (Business impact analysis):

ВХОДЫ

• Стратегия бизнеса
• Активы (компоненты)
• Угрозы и зависимости
• Уязвимости

ВЫХОДЫ

• Анализ рисков
• Управление рисками
• Способ восстановления услуги
• План восстановления сервиса(ITSC)

РОЛИ

Менеджер по управлению непрерывностью

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

МЕТРИКИ

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

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

• Сложно определить критически важные услуги для бизнеса, их количество
• Отсутствует поддержка процесса управления непрерывностью бизнеса (Business continuity management, BCM) со стороны ИТ
• Отсутствие руководства по принятию мер предотвращения чрезвычайных ситуаций, или уменьшения степени их воздействия.

РИСКИ

ВАЖНО!

ITSCM является важной частью процесса BCM. Эффективная реализация ITSCM без ВСМ на практике невозможна!

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

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

Управление доступностью (Availability Management, AVB)

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

ОПРЕДЕЛЕНИЯ

Доступность (Availability)

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

Надежность (Reliability)

доступность сервиса в течение согласованного периода времени без каких-либо сбоев

Отказоустойчивость (Resilience)

способность сервиса сохранять доступность при сбое одного или нескольких ИТ-компонентов

Ремонтопригодность (Maintainability)

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

Обслуживаемость (Serviceability)

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

Среднее время ремонта (Mean time to repair, MTTR)

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

Среднее время между сбоями (Mean time between failures, MTBF)

период работоспособного состояния (uptime), среднее время между восстановлением после одного сбоя и возникновением другого

Среднее время между системными инцидентами (Mean time between system incidents, MTBSI)

среднее время между двумя последовательными инцидентами. MTBSI=MTTR+MTBF

Анализ влияния отказа компонента (Component failure impact analysis, CFIA)

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

Анализ дерева неисправностей (Fault tree analysis, FTA)

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

Метод анализа и управления рисками (CCTA Risk analysis & management method, CRAMM)

метод, позволяющий определить меры по защите конфиденциальности, целостности и доступности ИТ-инфраструктуры

Анализ простоя системы (System outage analysis, SOA)

ВХОДЫ

• Бизнес-требования
• Требования к доступности
• Данные об INC, PRB, CI
• Достигнутые уровни сервиса

ВЫХОДЫ

• Критерий разработки принципов доступности и восстановления
• Устойчивость конфигурационных единиц (CI)
• Отчет о достигнутом уровне сервиса
• Мониторинг доступности
• План улучшения доступности

РОЛИ

Менеджер по управлению доступности

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

МЕТРИКИ

• Простой, недоступность обслуживания (минуты)
• Время обнаружения неполадки (минуты)
• Время реагирования на неполадку (минуты)
• Время устранения неполадки (минуты)
• MTBSI(среднее время между системными неполадками) (минуты)
• MTTR(среднее время прекращения простоя, среднее время восстановления) (минуты)

ВЛИЯНИЕ ПРИ ОТКАЗЕ ОТ ПРОЦЕССА

• Низкая удовлетворенность Заказчика
• Количество отказов в доступности к системам не известно
• Увеличение затрат на поддержку информационной среды

РИСКИ

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

ВАЖНО!

Соотношение MTBF и MTBSI показывает было ли много незначительных сбоев или же несколько серьезных нарушений в работе

Если Вы не измеряете, Вы не можете управлять

Если Вы не измеряете, Вы не можете улучшать

Если Вы не измеряете, Вам, вероятно, все равно

Если вы не можете влиять, то не стоит и измерять

Методологии

ITSM не является методологией или руководством к действию, но описывает передовой опыт (best practices) и предлагает рекомендации по организации процессного подхода и управления качеством предоставления услуг. Различные организации разработали свои методологии и модели управлению услугами на основе ITSM.

Внедрение управления услугами

Вопросам организации внедрения ITSM посвящена отдельная книга ITIL «Планирование внедрения управления услугами» («Planning to Implement Service Management»).

См. Также

• Литература

  • Евгений Аксенов, Игорь Альтшулер Аутсорсинг: 10 заповедей и 21 инструмент. — СПб.: Питер, 2009. — 464 с.: ил. — (Серия «Теория менеджмента»). ISBN 978-5-388-00539-7