Реферат управление ит услугами

метки: Управление, Сервис, Услуга, Мощность, Процесс, Затрата, Планирование, Предоставление

Для улучшения этой статьи желательно^? :

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

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

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

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

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

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

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

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

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

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

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

Эта задача требует персонального внимания со стороны Менеджеров по работе с Заказчиком, которые должны заблаговременно обеспечить наличие подробных планов работ с ФЗ.

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

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

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

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

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

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

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

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

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

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

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

• Принцип 1:

SZ должна сконцентрировать ресурсы с опытом в корпоративной ИТ-архитектуре, ИТ-стратегии, архитектуре приложений, технической ИТ-архитектуре. Предпосылка: SZ должен иметь в штате специалиста по корпоративной ИТ-архитектуре и специалиста по ИТ-стратегии.

• Принцип 2:

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

• Принцип 3:

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

• Принцип 4:

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

1. ITIL (IT Infrastructure Library)

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

2. Содержание

В настоящее время существует несколько версий библиотеки 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.

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

3.1. Служба Service Desk

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

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

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

3.2.1. ОПРЕДЕЛЕНИЯ

Инцидент (incident)

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

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

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

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

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

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

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

Эскалация

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

Цель — решить INC в срок указанный в SLA.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Закрытие

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

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

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

Отчетность

3.2.3. ВХОДЫ

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

3.2.4. ВЫХОДЫ

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

3.2.5. РОЛИ

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

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

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

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

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

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

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

3.2.7. МЕТРИКИ

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

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

Для бизнеса:

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

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

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

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

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

3.2.10. РИСКИ

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

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

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

3.3.1. ОПРЕДЕЛЕНИЯ

Проблема (problem)

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

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

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

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

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

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

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

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

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

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

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

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

Отчетность

3.3.3. ВХОДЫ

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

3.3.4. ВЫХОДЫ

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

3.3.5. РОЛИ

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

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

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

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

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

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

3.3.7. МЕТРИКИ

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

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

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

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

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

3.3.10. РИСКИ

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

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

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

3.4.1. ОПРЕДЕЛЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль CI

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

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

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

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

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

3.4.3. РОЛИ

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

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

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

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

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

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

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

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

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

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

3.4.6. МЕТРИКИ

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

3.4.7. РИСКИ

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

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

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

3.5.1. ОПРЕДЕЛЕНИЯ

Изменение

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

Запись об изменении (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, отвечающий за это изменения — закрывается

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

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

Все запросы делятся на два вида:

• Запросы на обслуживание (стандартные изменения) — полностью определённые и утвержденные изменения, регистрируемые, но не оценивающиеся процессом управления изменениями. Эти изменения проводятся в рабочем порядке.
• Запросы на CHG — все другие запросы на модификацию инфраструктуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5.3. ВХОДЫ

• RFC
• CMDB
• FSC

3.5.4. ВЫХОДЫ

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

3.5.5. РОЛИ

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

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

Участник САВ

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

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

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

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

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

3.5.7. МЕТРИКИ

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

3.5.8. РИСКИ

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

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

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

3.6.1. ОПРЕДЕЛЕНИЕ

Релиз (release)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6.3. ВХОДЫ

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

3.6.4. ВЫХОДЫ

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

3.6.5. РОЛИ

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

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

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

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

Менеджер DSL\DHS

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

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

3.6.7. МЕТРИКИ

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

3.6.8. РИСКИ

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

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

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

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

4.1.1. ОПРЕДЕЛЕНИЯ

Требование к уровню услуг (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)

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

Качество

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

ИТ сервис

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

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

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

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

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

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

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

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

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

4.1.3. ВХОДЫ

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

4.1.4. ВЫХОДЫ

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

4.1.5. РОЛИ

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

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

4.1.6. МЕТРИКИ

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

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

4.1.8. РИСКИ

---

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

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

4.2.1. ОПРЕДЕЛЕНИЯ

Составление бюджета (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)

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

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

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

Методы составления бюджета:

• Инкрементное (приростное) составление бюджета — в качестве основы для нового бюджета используются цифры за прошлый год. Они корректируются в соответствии с ожидаемыми изменениями в деятельности, затратах и ​​ценах организации.
• Составление бюджета «с нуля»: работа над бюджетом начинается с чистого листа бумаги «с нуля». Опыт прошлых лет не принимается в расчет. Это заставляет менеджеров определять все потребности в ресурсах, включенных в их бюджеты. Это означает, что необходимо проанализировать каждую статью расходов и принять решение об их осуществимости и стоимости.

Составление бюджета начинается с определения ключевых факторов, сдерживающих рост компании. Во многих случаях это объём продаж; однако, этими факторами могут также быть недостаток складского пространства, материалов и т. д. Часто бюджет определяют финансовые ограничения. Процесс составления включает в себя определение следующих вторичных бюджетов:

• Бюджет продаж и маркетинга: если бюджет определяется объемом продаж, большая часть работы ложится на отдел маркетинга. Для составления хорошего бюджета крайне необходимы точная оценка и анализ заказчиков, рынков, регионов сбыта, продуктов и т. д.
• Производственный бюджет — включает подробную информацию о предоставляемых услугах: количество, время поставки, необходимые затраты рабочей силы и материалов и т. д.
• Административные бюджеты — исходя из планируемых услуг необходимо определить бюджет на накладные расходы для соответствующих отделов, например, производственного отдела, отделов продаж и распространения, исследований и разработок и т. д.
• Бюджет затрат и инвестиций — этот бюджет состоит из затрат, включенных в вышеуказанные бюджеты. Инвестиционный бюджет определяет затраты, связанные с заменой и приобретением капитальных товаров.

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

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

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

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

Определение тарифов

Включает следующие действия:

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

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

• Издержки плюс фиксированная прибыль — стоимость + % наценки
• Текущая ставка предназначена для услуг, для которых уже существуют соглашения о ценообразовании.
• Получайте целевой доход — за услуги, стоимость которых была определена заранее.
• Рыночная ставка (допустимая на рынке) — цены, которые сопоставимы с ценами внешних поставщиков.
• Согласованная договорная цена — эти цены согласуются с заказчиком. Если клиенту нужна новая услуга, обсуждается, должна ли цена включать все инвестиционные затраты или только их часть.

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

4.2.3. ВХОДЫ

• Типы затрат

4.2.4. ВЫХОДЫ

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

4.2.5. РОЛИ

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

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

4.2.6. МЕТРИКИ

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

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

4.2.8. РИСКИ

---

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

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

4.3.1. ОПРЕДЕЛЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление возможностями бизнеса

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

• Разработка плана по мощностям
• Моделирование
• Определение размера технической платформы для работы ПО

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

    *анализ тенденции (самый дешевый способ);  

• аналитическое моделирование;
• имитационное моделирование ;

- тестирование в сравнении с некоторым базовым вариантом , также называемый бенчмаркинг.

Управление возможностями сервиса

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

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

Управление мощностями ресурсов

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

• Мониторинг
• Анализ
• Настройка с целью оптимизации систем
• Внедрение — ввод измененной или новой мощности
• Управление спросом

4.3.3. ВХОДЫ

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

4.3.4. ВЫХОДЫ

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

4.3.5. РОЛИ

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

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

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

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

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

4.3.8. МЕТРИКИ

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

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

4.3.10. РИСКИ

---

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

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

4.4.1. ОПРЕДЕЛЕНИЯ

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

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

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

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

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

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

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

Определение охвата (области действия) процесса управления непрерывностью ИТ-сервисов

• Определение политики
• Определение области действия процесса и других важных для процесса областей
• Выделение ресурсов
• Подготовка проектной организации

Требования и стратегия

• Анализ воздействия на бизнес

    *Анализ сервисов *Инфраструктура 

• Оценка рисков

    *Анализ рисков *Анализ угроз и зависимостей *Идентификация и классификация  *Оценка угроз и уязвимостей 

• Стратегия обеспечения непрерывности ИТ-сервисов

Внедрение

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

План восстановления должен включать:

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

• Классификация чрезвычайных обстоятельств
• Разделы для участвующих групп специалистов

    *Администрация *ИТ-инфраструктура *Персонал *Безопасность  *Площадки восстановления *Возврат к нормальным условиям 

4.4.3. ВХОДЫ

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

4.4.4. ВЫХОДЫ

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

4.4.5. РОЛИ

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

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

4.4.6. МЕТРИКИ

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

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

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

4.4.8. РИСКИ

4.4.9. ВАЖНО!

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

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

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

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

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

4.5.1. ОПРЕДЕЛЕНИЯ

Доступность (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)

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

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

• определение требований к доступности сервиса;
• проектирование систем для достижения требуемого Уровня Доступности;
• проектирование систем для достижения требуемой способности восстановления ;
• вопросы безопасности;
• управление обслуживанием;
• разработка Плана Доступности.

Мониторинг

• проведение измерений и составление отчетов. Ниже дается описание основных видов деятельности.

4.5.3. ВХОДЫ

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

4.5.4. ВЫХОДЫ

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

4.5.5. РОЛИ

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

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

4.5.6. МЕТРИКИ

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

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

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

4.5.8. РИСКИ

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

4.5.9. ВАЖНО!

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

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

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

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

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

---

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

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

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

5.1. ОПРЕДЕЛЕНИЯ

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

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

Целостность

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

Доступность

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

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

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

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

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

Оценка

Поддержка

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

5.1.2. ВХОДЫ

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

5.1.3. ВЫХОДЫ

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

5.1.4. РОЛИ

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

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

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

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

---

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

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

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

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

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

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

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

8. См. Также , Литература

[Электронный ресурс]//URL: https://management.econlib.ru/kursovaya/upravlenie-it-uslugami/

• Евгений Аксенов, Игорь Альтшулер Аутсорсинг: 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 с.

Данный реферат составлен на основе .