ITSM

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

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

Общее описание моделей Структурирование субъекта рынка (СР) в части ИТ должно производится по одной из моделей:

• Инсорсинг – использование внутренних специализированных ИТ-подразделений для оказания ИТ-услуг;
• Аутсорсинг – передача ИТ-функций на исполнение во внешнюю по отношению к субъекта рынка специализированную Сервисную Организацию (далее – СО);
• Смешанная модель (ряд сервисов предоставляется Сервисным подразделением субъекта рынка (Инсорсинг), другие сервисы предоставляются внешней Сервисной организацией (Аутсорсинг).

Служба Заказчика

Служба Заказчика (далее СЗ) – организационная структура, входящая в состав Субъекта Рынка (далее СР) и являющаяся (в терминах ГОСТ Р ИСО/МЭК 12207) Поставщиком ИТ-услуг для бизнес-подразделений (Функциональных Заказчиков, далее ФЗ) СР, Заказчиком для поставщиков ИТ-услуг, внешних по отношению к СР. В случае Инсорсинговой формы Сервисной Структуры (далее СС), она является для СЗ «внешней организацией».

Границы ответственности

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

Решаемые задачи Задачи, решаемые СЗ, распределены по следующим направлениям:

• Контроль удовлетворенности Заказчика:

СЗ обязана понимать потребности ФЗ и предоставлять необходимые ФЗ ИТ - решения, согласно контракту на сервисное обслуживание и соглашению об уровне оказываемых услуг(SLA). Эта задача требует персонального внимания со стороны Менеджеров по работе с Заказчиком, которые должны заблаговременно обеспечить наличие подробных планов работ с ФЗ.

• Управление СС:

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

• Управление ИТ-бюджетом:

Планирование и управление ИТ-бюджетом.

• Управление технологиями и инновациями:

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

• Управление критически важными для бизнеса проектами и программами:

Планирование, организация работ по реализации, управление реализацией.

• Управление ИТ-затратами:

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

Принципы построения Основополагающие принципы построения СЗ:

• Принцип 1:

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

• Принцип 2:

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

• Принцип 3:

СЗ должна обладать достаточным резервом опытных менеджеров проектов с хорошими знаниями специфики работы СР. Необходимое условие: специальные знания для ведения критически важных для Бизнеса проектов должны присутствовать как в СЗ, так и в СС.

• Принцип 4:

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

ITIL (IT Infrastructure Library)

Как наиболее известная часть ITIL, Управление IT-услугами (ITSM) нередко считается эквивалентным библиотеке ITIL в целом. Однако ITIL, хоть и включает в себя ITSM, описывает не только управление услугами, но и сопутствующие процессы.

Содержание

В настоящее время существует несколько версий библиотеки ITIL. Под ITIL версии 2 подразумеваются две книги: «Предоставление услуг» («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)

Под ITIL версии 3 подразумеваются пять книг: 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 (Непрерывное улучшение качества услуг)
  1. The 7-Step Improvement Process (7 шагов измерения и улучшения)
  2. Цикл Деминга (PDCA)

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

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

Служба Service Desk

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

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

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

ОПРЕДЕЛЕНИЯ

Инцидент (incident)

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

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

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

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

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

Запрос на Изменение (RFC)

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

Эскалация

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

Степень воздействия инцидента (impact) 

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

Срочность инцидента (urgency)

приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.

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

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

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

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

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

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

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

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

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

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

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

Закрытие

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

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

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

Отчетность

ВХОДЫ

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

ВЫХОДЫ

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

РОЛИ

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

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

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

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

Специалисты 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 — все другие запросы на модификацию инфраструктуры.

Источники RFC:

 * Управление Проблемами 
 * Заказчики 
 * Политика компании 
 * Законодательство 
 * Поставщики 
 * Проекты 
 * Любой другой сотрудник ИТ 

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

• Приоритет
• Категория

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

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

• Финансовое одобрение — анализ затрат/выгод и выделение бюджета.
• Техническое одобрение — оценка необходимости, возможности проведения изменения и его степени воздействия.
• Бизнес-одобрение — одобрение пользователями требуемой функциональности приложения и степени воздействия изменения.

Координация CHG

• Подготовка изменений
• Тестирование
• Внедрение

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

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

Проведение срочных изменений

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

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

ВХОДЫ

• 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)

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

Склад эталонного АО (definitive hardware library, DHS)

хранилище, предназначенное для хранения запасных аппаратных средств.

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

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

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

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

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

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

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

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

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

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

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

ВХОДЫ

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

ВЫХОДЫ

• Готовые релизы
• Сведения о измененных CI

РОЛИ

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

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

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

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

Менеджер 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 Improvement Program — 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
• Среднее время работоспособного состояния MTBF
• Среднее время прекращения простоя или среднее время восстановления MTTR = MTBSI - MTBF

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

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

РИСКИ

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

ВАЖНО!

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

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

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

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

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

---

Управление информационной безопасностью

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

Цели:

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

ОПРЕДЕЛЕНИЯ

Конфиденциальность 

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

Целостность 

точность, полнота и своевременность информации.

Доступность 

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

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

Контроль - политика и организация информационной безопасности

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

Реализация (внедрение)

Оценка

Поддержка

Составление отчетов

ВХОДЫ

• Соглашения SLA
• Определение требований безопасности по возможности дополненные документами, определяющими политику компании в этой области

ВЫХОДЫ

• Документ о достигнутой реализации соглашения SLA
• Отчеты о внештатных ситуациях
• Регулярные планы по безопасности

РОЛИ

Руководитель процесса

Инспектор информационной безопасности

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

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

---

Методологические принципы и стиль изложения положений ITSM

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

Методология ITSM не является конкретным алгоритмом или руководством к действию, но она описывает передовой опыт (best practices) и предлагает рекомендации по организации процессного подхода и управления качеством предоставления услуг. Это позволяет оторваться от особенностей данного конкретного предприятия в данной конкретной отрасли. Вместе с тем, несмотря на определённую абстрактность, ITSM всячески нацелено на практическое использование. В каждом разделе библиотеки приводятся ключевые факторы успеха внедрения того или иного процесса, практические рекомендации при этом превалируют над чисто теоретическими рассуждениями.

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

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

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

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

См. Также

• Cobit

Литература

• Евгений Аксенов, Игорь Альтшулер Аутсорсинг: 10 заповедей и 21 инструмент. — СПб.: Питер, 2009. — 464 с.: ил. — (Серия «Теория менеджмента»). ISBN 978-5-388-00539-7
• ИТ-Сервис-менеджмент. Введение. М. 2003 ISBN 90-77212-15-9
• Введение в реальный ITSM / Роб Ингланд; Пер. с англ. – М.: Лайвбук, 2010. – 132 с. ISBN 978-5-904584-05-4
• Овладевая ITIL / Роб Ингланд; Пер. с англ. – М.: Лайвбук, 2011. – 200 с. ISBN 978-5-904584-13-9
• Методическое руководство для подготовки к профессиональным экзаменам ISO 20000 Foundation и ISO 20000 Foundation Bridge / Будкова Л., Журавлёв Р. – М.: Клеверикс, 2010. – 124 с.