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

Основы управления информационнотехнологическими сервисами А.Н.Бирюков anbiryukov@fa.ru Что такое ИТ-менеджмент? ИТ-менеджмент – решение всей совокупности задач, связанных с ИТ предприятия или организации: научно-технических, организационных, управленческих, кадровых, финансовых, юридических и т.п. Ключевую роль в решении на этих задач на предприятии играет ИТ-организация (ИТ-служба, ИТ-департамент). В дальнейшем речь пойдёт, главным образом, об организационных и управленческих задачах. Что такое «управление ИТ-сервисами»? Управление информационно-технологическими сервисами (ИТ-услугами) – раздел ИТ-менеджмента. Распространённое название – ITSM (от англ. IT Service Management). В рамках управления ИТ-услугами вся деятельность ИТ-специалистов и руководителей рассматривается как подготовка, развитие и оказание ИТуслуг менеджерам и структурным единицам предприятия. Такой подход предполагает специфические методы управления деятельностью ИТ-службы. Бизнес-модель ИТ-организации и ИТ-компании В настоящее время общепринятым является взгляд на ИТкомпании и ИТ-организации, как на идентичные с точки зрения управления, сервисные организации. Часто они называются провайдерами ИТ-услуг. Каждая из них предоставляет услуги своим клиентам и получает услуги от своих поставщиков. ИТ-компании (внешние для предприятия провайдеры услуг) оказывают услуги не непосредственно потребителям внутри предприятия, а ИТ-организации, которая использует эти услуги для оказания собственных ИТ-услуг. Место ИТ-организации Внутренний рынок предприятия ИТ-рынок Внутренние заказчики ИТ-услуг Внешние заказчики ИТ-услуг ИТ-организация Внешний провайдер ИТ-услуг (ИТкомпания) Специфика внутреннего рынка ИТ-услуг • Состав субъектов рынка неизменен • Субъекты рынка разделяют общие цели (цели предприятия) • Субъекты рынка неравноправны • Отсутствует независимый механизм урегулирования споров и контроля исполнения обязательств • Отсутствует свободная конкуренция (ИТ-служба – монополист) • ИТ-служба не свободна в выборе клиентов Процессное управление и ИТ-услуги • Современный подход к управлению ИТ-услугами базируется на концепции процессного управления • Процессный подход к управлению ИТ-услугами позволяет обеспечить качество ИТ-услуг • Для реализации процессов управления ИТ-услугами, как правило, используются референтные процессные модели («лучшие практики») (ITIL, ISO 20000) • Референтные процессные модели для управления ИТ-услугами постоянно совершенствуются и развиваются Основные роли заказчиков ИТ-услуг • Рядовые участники бизнес-процессов • Ответственные исполнители бизнес-процессов (менеджеры/администраторы процессов) • Владельцы бизнес-процессов (часто линейные менеджеры) • Высшее руководство предприятия • Собственники предприятия Основные задачи ролей в процессе (CBOK 3.0) • Владелец процесса: • формирует команду, определяющую контекст процесса и его связь с целями предприятия, • формирует команду, проектирующую процесс, • служит контактным лицом по всем вопросам, связанным с процессом, • мониторит исполнение и отчитывается перед руководством, • возглавляет команду по по оценке, определению приоритетов и реализации запросов на изменения процесса. Основные задачи ролей в процессе (CBOK 3.0) • Администратор процесса: • является непосредственным руководителем персонала, исполняющего действия в процессе, • накапливает знания и опыт в рамках функциональной области, • привлекает и удерживает сотрудников, • структурирует и описывает роли в функциональной команде, • мониторит исполнение и отчитывается перед руководством, • возглавляет команду по по оценке, определению приоритетов и реализации запросов на изменения процесса, • Описывает и поддерживает процедуры операционного уровня. Важные замечания… • Единый общепринятый перечень ролей при процессном подходе к управлению не выработан и, по-видимому, не будет выработан; все существующие роли имеют рекомендательный характер • Основная идея при определении перечня ролей состоит в разумном разделении ответственности за бизнес-процесс (т.е., таком, при котором нет конфликта ответственностей) • При необходимости предприятия могут разделять роли на более мелкие при условии, что не возникает конфликта интересов и ответственности • Один и тот же сотрудник может быть носителем нескольких ролей Клиенты и услуги ИТ-организации Бизнес-организация Участники бизнеспроцессов Владельцы и менеджеры бизнеспроцессов Руководство организации и уполномоченные менеджеры Владельцы и инвесторы Комплексная автоматизация, управление корпоративными данными, стратегическое планирование ИТ, оптимизация ИТбюджета Защита ИТинвестиций, снижение ИТрисков, отраслевая экспертиза Услуги Адаптация к индивидуальным требованиям, индивидуальная настройка Автоматизация бизнеспроцессов и групп бизнеспроцессов ИТ-организация Примеры услуг для участников бизнеспроцессов • Обеспечение контроля за вводом данных • Обеспечение целостности общих данных • Автоматизация рутинных операций • Минимизация последствий ошибок • Оперативное и эффективное реагирование ИТ-службы на запросы участников • Обеспечения доступа к ИТ-ресурсам предприятия (бизнесприложениям, коммуникациям, информационным хранилищам) Примеры услуг для владельцев и менеджеров бизнес-процессов • Реализация модели контракта жизненного цикла для работ по автоматизации бизнес-процессов • Обеспечение качества результатов автоматизации (программнотехнических решений) • Обеспечение качества процессов автоматизации • Обеспечение качества ИТ-проектов Примеры услуг для руководства предприятия • Подготовка рекомендаций по выбору подхода к автоматизации бизнеспроцессов (определение и обоснование приоритетов автоматизации) • Снижение совокупных затрат на автоматизацию в масштабах предприятия (например, за счёт использования решений одного вендора/поставщика услуг или единого подхода к интеграции приложений) • Экспертные и консультационные услуги (например, оценка перспективности для предприятия определённых ИТ) • Организация взаимодействия с субъектами ИТ-рынка (организация презентаций вендоров, партнёров, консультантов) • Управление ИТ-рисками, качеством в ИТ, корпоративными данными (для уполномоченных менеджеров, например, директора по качеству или CDO) Примеры услуг для собственников предприятия • Защита инвестиций в ИТ (например, за счёт использования апробированных решений и технологий) • Снижение ИТ-рисков (например, за счёт использования проверенных партнёров и соисполнителей) • Обеспечение роста капитализации компании (например, за счёт использования инновационных ИТ) • Услуги отраслевой ИТ-экспертизы Основные концепции, на которых базируются референтные модели управления ИТ-услугами 1. Набор ИТ-услуг всякой ИТ-службы фиксирован. Перечень услуг (он обычно называется каталогом услуг) пересматривается только по взаимному согласию ИТслужбы и её клиентов, и происходит это достаточно редко (обычно ежегодно). В промежутках между обновлениями каталога услуг и клиенты и ИТ-служба накапливают и анализируют данные о фактическом потреблении ИТ-услуг и готовят предложения по пересмотру каталога. Основные концепции, на которых базируются референтные модели управления ИТ-услугами 2. Отношения ИТ-службы с клиентами основываются на договорном подходе. Договор между ИТ-службой и клиентом (называемый обычно соглашением об уровне обслуживания) является не строгим юридическим документом, а служит лишь для точного описания полномочий и ответственностей сторон. Период его действия совпадает с периодом действия каталога услуг. Таким образом, предполагается, что соглашение об уровне обслуживания действует достаточно долго и периодически пересматривается по взаимному согласию сторон. Основные концепции, на которых базируются референтные модели управления ИТ-услугами 3. ИТ-служба взаимодействует со своими клиентами очень специальным образом – через «единое окно», называемое обычно «службой сервис-деск» (от англ. Service Desk – пункт обслуживания), т.е., с точки зрения ИТ-службы, все клиенты равны, ни у кого нет возможности получить услугу «вне очереди», организованной и поддерживаемой ИТ-службой. «Неправильная» организация управления ИТуслугами 20 «Правильная» сервисная организация (лучшие практики) Процессы ITSM 21 Референтные модели процессов управления ИТ-услугами Что содержат референтные модели • Структуру процессов, обычно в наглядном (графическом) виде • Описания процессов, обычно на естественном языке, но в рамках заданного структурированного шаблона • Неформальные пояснения к процессам (не всегда) • Иллюстрирующие примеры (не всегда) Примеры референтных моделей • Модель процессов PMBoK • Модель процессов COBIT • Модель процессов ISO 12207 • Модель процессов ITIL • Модель процессов ISO 20000 • Модель процессов CMM/CMMI Цепь добавленной стоимости провайдера ИТуслуг Вспомогательная деятельность = процессы, не создающие стоимость Стратегическое управление Управление ИТ-финансами Управление ИТ-персоналом Управление взаимоотношениями с клиентами, поставщиками и партнёрами Управление проектами Управление процессами Управление ИТ-инфраструктурой Управление ИТ-активами Управление информационной безопасностью Управление инновациями Маркетинг (анализ требований клиента) и продажа Проектирование Входная и разработка логистика услуги (закупка услуг у внешних поставщиков) Производство Постоянное улучшение (оказание услуги услуги) Утилизация услуги Основная деятельность = процессы жизненного цикла продуктов/услуг (процессы, создающие стоимость) 25 Процессы, обычно входящие в референтные модели ITSM Вспомогательная деятельность = процессы, не создающие стоимость Стратегическое управление Управление ИТ-финансами Управление ИТ-персоналом Управление взаимоотношениями с клиентами, поставщиками и партнёрами Управление проектами Управление процессами Управление ИТ-инфраструктурой Управление ИТ-активами Управление информационной безопасностью Управление инновациями Маркетинг (анализ требований клиента) и продажа Проектирование Входная и разработка логистика услуги (закупка услуг у внешних поставщиков) Производство Постоянное улучшение (оказание услуги услуги) Утилизация услуги Основная деятельность = процессы жизненного цикла продуктов/услуг (процессы, создающие стоимость) 26 История ITIL/ITSM 80-е гг. – Библиотека ITIL (IT Infrastructure Library) (Central Computer and Telecommunications Agency — CCTA, сейчас Office of Government Commerce — OGC ) 80-90-е гг. – коммерческие продукты на базе ITIL (ITSM - Hewlett Packard, IT Process Model – IBM, MOF - Microsoft) 2000-е гг. – книги по ITSM (itSMF,it Service Management Forum). 1999 г. – 1-е изд-е кн. Введение в ИТ Сервис Менеджмент 2007 г. – ITIL версии 3 2011 г. – ITIL версии 2011 ITIL v.2 Ядро ITIL v.2 - 10 книг, в которых описывались как поддержка услуг и предоставление услуг. Библиотека включала также около 40 других книг по вспомогательным предметам, имевшим отношение к управлению ИТ-услугами, от монтажа кабелей до управления отношениями с заказчиком. В первоначальных сериях книг вопросы управления ИТ-услугами рассматривались главным образом с точки зрения ИТ. Для заполнения разрыва между бизнес-практикой и ИТ-организацией в библиотеку была включена серия книг, рассматривающая бизнес-аспекты управления ИТ-услугами. Основы ITIL v.2 представлены в двух книгах: по поддержке услуг и по их предоставлению. Взаимосвязи процессов ITSM в ITIL v.2 Предоставление услуг В книге «Предоставление услуг» описываются следующие вопросы: Управление уровнем услуг (уровнем обслуживания); Управление финансами ИТ; Управление мощностями; Управление непрерывностью ИТ-услуг; Управление доступностью. Отдельная книга посвящена управлению безопасностью (эти процессы не входят в Управление уровнем услуг). Управление уровнем обслуживания Целью управления уровнем услуг (уровнем обслуживания) является достижение ясных соглашений с заказчиком об ИТ-услугах и реализация этих соглашений. Для этого необходима информация о потребностях заказчика, о предоставляемых ИТ-службой технических средствах и об имеющихся финансовых ресурсах. Основные вопросы : • как оптимизировать ИТ-услуги для их предоставления заказчикам по доступным ценам на основе точных договоренностей в соглашении об уровне услуг (соглашении об уровне обслуживания) • как проводить мониторинг и обсуждение услуг; • как организовать поддержку услуг через внешние договоры с поставщиками. Управление финансами ИТ Управление финансами касается экономических вопросов предоставления ИТ-услуг. Например, процесс управления финансами подготавливает информацию о расходах, возникших при предоставлении услуг. В результате при определении необходимых изменений ИТ-инфраструктуры или ИТ-услуг возможен учет финансовых факторов (соотнесение расходов и доходов — цены и результата). Определение, отнесение расходов, их прогноз и отслеживание в ITIL v.2 называются «бюджетированием и бухгалтерским учетом». Эта деятельность повышает информированность о расходах (где возникают издержки и какие) и может использоваться также при составлении бюджета. Управление мощностями Управление мощностями представляет собой процесс оптимизации расходов, времени приобретения и размещения ИТ-ресурсов с целью обеспечения выполнения договоренностей с заказчиком. Процесс управления мощностями имеет дело с управлением ресурсами, управлением производительностью, управлением спросом на ИТ-услуги, моделированием, планированием мощностей, управлением нагрузкой и определением необходимого объема технических средств для работы приложений. При управлении мощностями акцент делается на планировании для обеспечения согласованного уровня обслуживания сейчас и в будущем. Управление доступностью Управление доступностью является процессом, обеспечивающим соответствующее размещение ресурсов, методов и технологий для поддержки уровня доступности ИТ-услуг, согласованного с заказчиком. Управление доступностью занимается такими вопросами, как оптимизация обслуживания и разрабатывает способы минимизации количества инцидентов, например, за счёт планово-предупредительных ремонтов оборудования и обновлений ПО или создания пула поставщиков внешних услуг. Управление непрерывностью ИТ-услуг Этот процесс касается подготовки и планирования способов устранения чрезвычайных ситуаций с ИТ-услугами в случае остановки бизнеса. Этот процесс уделяет основное внимание связям между всеми компонентами, необходимым для обеспечения непрерывности деятельности компании при катастрофах (т. е. для управления непрерывностью бизнеса), а также средствам предотвращения таких катастроф. Управление непрерывностью ИТ-услуг является процессом планирования и координации технических, финансовых и управленческих ресурсов, необходимых для обеспечения непрерывности услуг после катастроф, в соответствии с договоренностью с заказчиком. Поддержка услуг В книге ITIL v2. по поддержке услуг описывается, как заказчик может получить доступ к соответствующим услугам для поддержки своего бизнеса, и как эти услуги связаны между собой. Эта книга охватывает следующие области: Служба Service Desk; Управление инцидентами; Управление проблемами; Управление конфигурациями; Управление изменениями; Управление релизами. Служба Service Desk Служба Service Desk является точкой контакта пользователя с ИТ-организацией. Ранее в книгах ITIL она называлась службой Help Desk. Основными задачами службы Help Desk были регистрация, решение и отслеживание инцидентов. Служба Service Desk имеет более широкие функции (например, получение запросов на изменения) и может выполнять действия, относящиеся к нескольким процессам. Управление инцидентами Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие управления ИТ-услугами. Хотя это разграничение иногда может запутывать, но его главное достоинство заключается в установлении различия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением. Процесс управления инцидентами предназначен для устранения инцидента и быстрого возобновления предоставления услуг. Инциденты регистрируются, причем качество регистрационной информации определяет эффективность ряда других процессов. Управление проблемами Если возникло подозрение о существовании проблемы в ИТ-инфраструктуре, то целью процесса управления проблемами является установление и разрешение этой проблемы. Подозрение может возникнуть, например, из-за наличия инцидентов. Безусловной целью процесса является предотвращение сбоев везде, где это возможно. Когда причины установлены (определены известные ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре для предотвращения возникновения новых инцидентов. Такие улучшения производятся путем подачи запросов на изменение. Управление конфигурациями Задачами управления конфигурациями являются контроль изменяющейся ИТ-инфраструктуры (стандартизация и мониторинг статуса), идентификация конфигурационных единиц (инвентаризация, верификация и регистрация), сбор документации по ИТ-инфраструктуре и управление ею, а также предоставление информации об ИТ-инфраструктуре всем остальным процессам. Управление изменениями Управление изменениями контролирует изменения в ИТ-инфраструктуре. Целью процесса является определение необходимых изменений и способов их проведения с минимальным негативным воздействием на ИТ-услуги, при одновременном обеспечении контроля (отслеживании) изменений посредством консультаций и координации действий со всей организацией. Изменения производятся по запросу от заказчика, из процесса управления проблемами или из некоторых других процессов. Управление изменениями тесно связано с деятельностью по мониторингу статуса элементов из процесса управления конфигурациями. Внесение изменений производится согласно разработанной схеме, включающей определение, планирование, создание и испытание, принятие окончательного решения о проведении, внедрение и оценку. Управление релизами Релизом называется набор конфигурационных единиц, которые совместно тестируются и вводятся в активную рабочую среду. Главной задачей управления релизами является обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранение. Управление релизами обеспечивает гарантию того, что в использовании находятся только тестированные и корректные версии авторизованного программного и аппаратного обеспечения. Управление релизами тесно связано с деятельностью по управлению конфигурациями и управлению изменениями. Реальное внесение изменений часто выполняется через действия в рамках процесса управления релизами. Два процесса, не отнесенные к предоставлению услуг Деятельность по управлению взаимоотношениями с заказчиком ИТ-услуг включается в несколько процессов. Служба Service Desk является первой точкой контакта для пользователей. На самом деле заказавший услугу клиент первоначально вступает во взаимодействие с процессом управления взаимоотношениями с заказчиком ИТ-услуг, который помогает организовать коммуникации между ИТ-организацией, и её бизнесзаказчиками. Целью процесса управления информационной безопасностью является защита ИТ-инфраструктуры от несанкционированного использования (например, от несанкционированного доступа к данным). Такая защита основана на требованиях безопасности, заложенных в соглашениях об уровне обслуживания, контрактных требованиях, законодательстве, правилах работы компании и базовом уровне безопасности. Пример описания процесса в ITIL v.2: Управление инцидентами Управление Инцидентами. Определение 45 Управление инцидентами. Определение Задача процесса управления инцидентами — уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТуслуг, что позволяет быстро восстановить работу пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Фокусной точкой процесса управления инцидентами обычно является функция Service Desk, которая играет роль центра контактов пользователей с внутренними коллективами технических служб. Управление инцидентами является основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры. 46 Управление инцидентами. Термины Инцидент — это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги. В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также запросы на обслуживание (SR). Запрос на обслуживание — это запрос от пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры. Запрос на изменение (RFC) — это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом запросе на изменение какой-либо конфигурационной единицы (КЕ) в ИТ-инфраструктуре. Запрос на изменение считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения. 47 Управление Инцидентами. Термины При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями соглашений об уровнях обслуживания (Service Level Agreements — SLAs) служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со службой Service Desk. Приоритет определяется на основе срочности и степени воздействия: • степень воздействия инцидента - степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес-процессов, подвергшихся воздействию инцидента; • срочность инцидента - приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий. 48 Управление Инцидентами. Термины Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с приоритетами и, соответственно, временем разрешения инцидента. • Функциональная эскалация (горизонтальная) — означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения. • Иерархическая эскалация (вертикальная) — означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов. Задачей руководителя процесса управления инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов. 49 Управление Инцидентами. Термины Линии поддержки при функциональной эскалации. 1-я линия поддержки (поддержка 1-го уровня) - обычно служба Service Desk, 2-я линия — подразделения, осуществляющие управление ИТ-инфраструктурой, 3-я линия — отделы разработки и архитектуры программного обеспечения, 4-я линия — поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях руководитель процесса управления инцидентами может назначить координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. 50 Управление Инцидентами. Источники возникновения инцидента • Обнаружен пользователем: он докладывает об инциденте в службу Service Desk. • Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки. • Обнаружен сотрудником службы Service Desk: сотрудник производит регистрацию инцидента. • Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в службу Service Desk. 51 Управление Инцидентами. Цель процесса Целью процесса управления инцидентами является скорейшее восстановление нормального уровня обслуживания, определенного в соглашении об уровне услуг, с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, процесс управления инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов. 52 Управление Инцидентами. Процесс 53 Управление Инцидентами. Конфигурационная база данных (CMDB) Конфигурационная база данных (КБД, Configuration Management Database — CMDB) определяет связь между ресурсами, услугами, пользователями и уровнями обслуживания. Например, КБД содержит информацию о том, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, она помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь с соответствующей конфигурационной единицей (КЕ), позволяющая предоставить более подробную информацию об источнике ошибки. В случае необходимости может быть обновлен статус соответствующего компонента в КБД. 54 Управление Инцидентами. Процесс – 1/2 • Прием и регистрация инцидента — принимается сообщение и создается запись об инциденте. • Классификация и начальная поддержка — присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т. п. Пользователю может быть предложено возможное решение, даже если оно только временное. • Если вызов касается запроса на обслуживание, то инициируется соответствующая процедура. • Привязка — проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути. 55 Управление Инцидентами. Процесс – 2/2 • Расследование и диагностика — при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу. • Решение и восстановление — если решение найдено, то работа может быть восстановлена. • Закрытие — с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт. • Мониторинг хода работ и отслеживание — весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация. 56 Управление Инцидентами. Что важно при классификации инцидентов • Приоритет — это номер, определяющийся срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не исправить быстро). Приоритет = срочность х степень воздействия. • Услуги, подвергшиеся воздействию инцидента — может быть использован перечень существующих соглашений об уровнях обслуживания. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA. • Группа поддержки — если Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях инцидентов. Правильное распределение инцидентов имеет существенное значение для эффективности процесса управления инцидентами. 57 Управление Инцидентами. Что важно при классификации инцидентов • Сроки решения — с учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе. • Идентификационный номер — абонент информируется о номере инцидента для его точной идентификации при последующих обращениях. • Статус - Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть: • новый; • принят; • запланирован; • назначен; • активный; • отложен; • разрешен; • закрыт. 58 Управление Инцидентами. Расследование и диагностика Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня. В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника. 59 Управление Инцидентами. Решение и восстановление После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в сиcтему. В некоторых случаях необходимо направить запрос на изменение в процесс управления изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается в статусе «активный». 60 Управление Инцидентами. Закрытие После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, услугах, подвергшихся воздействию инцидента и конфигурационной единице, вызвавшей сбой. 61 Управление Инцидентами. Мониторинг хода решения и отслеживание В большинстве случаев ответственной за мониторинг хода решения является служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений. 62 Управление Инцидентами. Контроль процесса. Возможные показатели эффективности • Общее количество инцидентов; • среднее время разрешения инцидентов; • среднее время разрешения инцидентов по приоритетам; • среднее число инцидентов, разрешенных в рамках соглашений (SLA); • процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы); • средняя стоимость поддержки на инцидент; • число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk; • инциденты, решенные без посещения пользователя (удаленно); • число (или процент) инцидентов с первоначально некорректной классификацией; • число (или процент) инцидентов, неправильно распределенных в группы поддержки. 63 Управление Инцидентами. Контроль процесса. Функции и роли Руководитель Процесса Управления Инцидентами Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее: • мониторинг эффективности и рациональности работы процесса; • контроль работы групп поддержки; • составление рекомендаций по совершенствованию работы процесса; • развитие и сопровождение системы Управления Инцидентами. Персонал групп поддержки Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов. Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов. 64 Управление Инцидентами. Предположения Чтобы конвейерная обработка инцидентов была эффективной, требуется выполнение ряда неявных предположений. Эти предположения необходимо принимать во внимание при анализе применимости ITIL v2. 65 Предположение о массовости инцидентов Целью процесса обработки инцидентов является сокращение суммарного времени обработки инцидентов (при этом некоторые инциденты могут выполняться дольше, чем если бы они обрабатывались вне конвейера). Это оправданно, если инцидентов очень много, и суммарное время обработки важнее, чем индивидуальное. Конвейер (последовательность линий поддержки) позволяет разгрузить очередь инцидентов за счет разделения труда и распараллеливания, но не обязательно реализует оптимальную последовательность операций для каждого конкретного инцидента. Он идеален для одинаковых и простых инцидентов. 66 Предположение о сходстве структуры инцидентов Все инциденты должны быть «похожи» в том смысле, что их структура одна и та же. Это структура, свойственная техническим объектам (имеющим спецификацию или BOM), ремонт которых, во-первых, выполняется в фиксированном порядке, и во-вторых, всегда ориентирован на снижение себестоимости, т.е., выполняется от простых (требующих меньшей квалификации) операций к сложным (требующим более высокой квалификации) операциям. 67 Предположение о синхронности производства Время выполнения работ на каждой линии техподдержки предсказуемо и постоянно для всех инцидентов. Это позволяет подобрать, исходя из статистики инцидентов, оптимальную численность персонала линий техподдержки. Оптимизация состава и численности персонала линий техподдержки – единственный механизм управления производительностью конвейера. В этом отношении конвейер ITIL v2. – типичный пример «бережливого производства». 68 Примеры ИТ-услуг из ITIL v2. • Информационные услуги (запросы документации, экспертные услуги ИТ-специалистов) • Технические услуги (ремонт оборудования, восстановления работоспособности оборудования, обновление ПО, исправление ошибок в ПО) • Типовые или массовые комплексные услуги (оборудование рабочего места пользователя ИС, предоставления доступа к средствам коммуникации) Выводы по ITIL v2. • Структура процессов ITIL v2. предполагает, что ИТ-служба является на предприятии обслуживающим подразделением и центром затрат • Понятие ИТ-услуги не детализируется; точного определения ИТ-услуги нет (хотя примеры ИТ-услуг имеются) • Технологической основой модели является КБД, обеспечивающая целостность информации, необходимой для предоставления услуг • Наиболее формализованные процессы (управление инцидентами, управление конфигурациями, управление финансами, управление уровнем обслуживания) обобщают практики оказания преимущественно технических услуг и не обобщаются на более сложные услуги Проблемы с внедрением референтных моделей • Решающая роль во внедрении референтной модели (как и при любом инжиниринге процессов) принадлежит руководству. Среди руководителей должен найтись спонсор проекта внедрения, который возьмёт на себя ответственность за результат проекта. • Задача определения набора ролей и наложения ролей на оргструктуру остаётся открытой. Это сложная задача из-за изменения должностных инструкций персонала и возрастанием нагрузки на персонал. • Вопрос о том, какие процессы из референтной модели нужно внедрять требует глубокого анализа стратегии и тактики бизнеса. • Процесс внедрения очень трудоёмок и не всегда может быть выполнен предприятием самостоятельно. Управление уровнем услуг Управление уровнем услуг Управление уровнем услуг — это процесс, в рамках которого происходят переговоры по вопросам предоставления услуг, производится определение, измерение (оценка), управление и улучшение качества ИТ-услуг при соблюдении приемлемого уровня затрат. Процесс управления уровнем услуг помогает найти нужный баланс между предложением и спросом на услуги требуемого уровня качества услуги, легкостью в использовании и стоимостью услуги. Это понимание реализуется в разработке, согласовании и выполнении соглашений об уровне услуг (Service Level Agreements, SLA), операционных соглашений об уровне услуг (Operational Level Agreements,OLA), внешних договоров (Underpinning Contracts, UC) и плана обеспечения качества услуг (Service Quality Plan, SQP). 73 Управление уровнем услуг. Термины Поставщики и заказчики ИТ-услуг Теоретически, любой, кто получает ИТ-услуги, является заказчиком. В большинстве случаев ИТ-организация является поставщиком, но поскольку обычно она тоже получает ИТ-услуги, то одновременно выступает и как заказчик ИТ-услуг у внешних провайдеров. Все это создает достаточно сложную (и часто замкнутую) сеть взаимоотношений. Используемые определения: • заказчик — представитель организации, у которого есть полномочия на заключение соглашений от лица организации на получение ИТ-услуг. Поэтому заказчик и конечный пользователь услуг — не одно и то же. • поставщик — представитель организации, у которого есть полномочия на заключение соглашений о предоставлении ИТ-услуг. 74 Управление уровнем услуг. Термины • Требования к уровню услуг (Service Level Requirements — SLR) • Требования к уровню услуг представляют собой детальное описание потребностей заказчика, они используются при разработке, модификации и инициировании услуг. Требования можно использовать в качестве прототипа при разработке соглашения об уровне услуг, а также как Техническое задание. • Таблицы спецификации услуг (Service Specification Sheets — Spec Sheets) Таблицы спецификаций используются для описания взаимосвязей между функциональностью, согласованной с заказчиком, и технологией, используемой в ИТорганизации, и содержат детальные спецификации услуг. Они помогают преобразовать требования к уровню услуг в технические определения, необходимые для предоставления этой услуги. Кроме того, они описывают связи между SLA, OLA и UC. Таблицы спецификаций являются важным инструментом мониторинга соответствия внутренних спецификаций внешним. 75 Управление уровнем услуг. Термины Каталог услуг (Service Catalog) Разрабатывая каталог услуг, ИТ-организация создает о себе представление как о поставщике ИТ-услуг, а не просто как о технологической организации, выполняющей внедрение и сопровождение технических средств и ПО. Каталог содержит подробное описание действующих услуг, а также описание уровней услуг, которые организация может предложить своим заказчикам. Каталог услуг может помочь в формировании ожиданий пользователя и тем самым облегчить процесс согласования целей и задач заказчика и поставщика услуг. Каталог создается на основе внешних спецификаций и поэтому должен быть написан понятным заказчику языком, а не языком технических спецификаций. 76 Управление уровнем услуг. Термины Соглашение об уровне услуг (Service Level Agreement — SLA) Соглашение об уровне услуг представляет собой соглашение между ИТ-организацией и заказчиком, в котором подробно оговорены предоставляемые услуги. Оно является стандартом при оценке и корректировке ИТ-услуг. Соглашение может иметь иерархическую структуру, например, услуги общего характера, такие как сетевые услуги и услуги службы Service Desk, определяются для всей организации и утверждаются руководством. Услуги более конкретного характера, предназначенные для бизнес-деятельности, согласуются на более низком уровне, например, с руководством бизнес-подразделения, владельцем бюджета или представителем заказчика. 77 Управление уровнем услуг. Термины Программа улучшения услуг (Service Improvement Program — SIP) Часто реализуется как проект, в рамках которого определяются виды деятельности по улучшению качества ИТ-услуг, этапы и контрольные точки в данной работе. План обеспечения качества услуг (Service Quality Plan — SQP) В нем определены целевые значения параметров процессов управления услугами и методы их достижения. Например, для процесса управления инцидентами план может определять время разрешения для инцидентов в зависимости от степеней их воздействия. Для всех процессов определяются виды отчетов и сроки их предоставления. Показатели эффективности разрабатываются на основе требований к уровню услуг и заносятся в таблицы спецификаций. 78 Управление Уровнем Услуг. Термины Операционное Соглашение об Уровне Услуг (Operational Level Agreement — OLA) Это соглашение с подразделением ИТ-организации, в котором конкретизируются договоренности о предоставлении определенных элементов услуг, например, доступности сети или доступности серверов печати. Например, если SLA содержит временные показатели в разрешении инцидентов с высоким приоритетом, то OLA должно определять цели для каждого элемента цепочки поддержки (параметры для службы Service Desk — время ответа на звонки, эскалация инцидентов и т. д., параметры для cлужбы поддержки сети — сроки расследования и устранения сетевых ошибок и т. д.). Внешний Договор (Underpinning contract — UC) Это договор с внешним поставщиком, который определяет договоренности по предоставлению конкретных услуг, например, поддержку рабочих станций или аренду линии связи. Действие такого договора аналогично внешней реализации OLA, но договор с внешним поставщиком обычно оформляется в форме официального правового документа. 79 Управление уровнем услуг. Цель процесса Процесс управления уровнем услуг гарантирует постоянную поддержку и совершенствование требуемых заказчиком ИТ-услуг. Это достигается путем согласования уровня качества услуг ИТ-организации, их мониторинга и предоставления отчетов, что способствует установлению эффективных взаимоотношений между ИТорганизацией и ее заказчиками. 80 Управление уровнем услуг. Преимущества от процесса Использование процесса управления уровнем услуг может дать следующие преимущества: • поскольку ИТ-услуги разрабатываются в соответствии с требованиями, они, будут отвечать ожиданиям заказчика; • качество услуг можно будет оценить/измерить, значит, им можно будет управлять; • если ИТ-организация выставляет счета заказчику за пользование ИТ-услугами, заказчик сможет сопоставить качество услуг с выставленной в счете стоимостью; • поскольку ИТ-организация может создавать спецификации требуемых услуг и их компонентов, она может полноценно управлять ресурсами и снижать затраты; • улучшаются отношения с заказчиками; • и заказчик, и ИТ-организация знают о своих обязанностях и ролях, следовательно, будет меньше недопонимания и упущений. 81 Управление уровнем услуг. Процесс В процесс входят следующие задачи: • интеграция элементов, необходимых для предоставления ИТ-услуг; • документирование услуг путем описания их элементов в различных документах; • описание предоставляемых заказчику услуг на понятном и удобном для заказчика языке; • согласование ИТ-стратегии с потребностями бизнеса; • контролируемое улучшение предоставления ИТ-услуг. Управление уровнем услуг играет центральную роль в процессах ITSM. Этот процесс обеспечивает возможность обсуждать бизнес-потребности заказчика, не углубляясь в технические детали. Затем запросы заказчика ИТ-организация преобразует в технические спецификации и конкретные виды деятельности. Степень невовлеченности заказчика в технологические вопросы является показателем успешной работы процесса. 82 Управление уровнем услуг. Последовательность работ Здесь показаны два компонента, составляющие процесс, которые во многом выполняются параллельно: • первый, более высокого уровня, связан с выработкой договоренностей, • второй, более низкого уровня, — с обеспечением их выполнения. 83 Управление уровнем услуг. Роли. Контроль за процессом управления уровнем услуг осуществляет руководитель процесса. Он должен обеспечить эффективность процесса и достижение заданных результатов. Роль руководителя процесса не обязательно исполняет один человек. Во многих организациях есть несколько руководителей процесса, каждый из которых отвечает за одну или несколько услуг или групп заказчиков. Руководитель процесса управления уровнем услуг отвечает за: • создание и обновление каталога услуг; • создание и поддержание эффективного процесса управления уровнем услуг, включая: • определение структуры SLA; • заключение OLA и UPC; • обновление существующего Плана улучшения услуг; • ведение переговоров с заказчиками, заключение и поддержка SLA, OLA, UPC; • анализ качества работы ИТ-организации и улучшение качества услуг по мере необходимости. 84 Управление уровнем услуг. Выводы • Договорной подход к взаимодействию ИТ-организации и бизнес-организации не предполагает санкций: полноценное договорное взаимодействие адекватно для регулирования отношений независимых, самостоятельных и равноправных контрагентов, несущих равную ответственность • Внутренняя «правовая среда» для договорного взаимодействия, как правило, отсутствует • Управление уровнем услуг не описывает конкретных форматов SLA, OLA, UC и т.п. • Роль владельца процесса абсолютно ключевая: все конкретные решения принимаются именно им. Это Архитектор/Главный конструктор и CIO в одном лице. • Предполагается, что в основном услуги стабильны, иначе каталог услуг и SLA не имеют смысла. • Процесс не связан со структурой организации: SLA/OLA/UC лишены структуры, обеспечение целостности структуры договоров не описано (SLA/OLA/UC не входят в КБД и не попадают в область охвата управления изменениями). 85 ITIL v.2011 Управление услугами в ITIL v.2011 Жизненный цикл услуг Развёртывание услуг Стратегия оказания услуг Реализация услуг Проектирование услуг Непрерывное улучшение услуг Определения Результат: Результат выполнения активности, исполнения процесса, оказания ИТ-услуги и т.п. Термин относится не только к желаемым, но и к фактическим результатам. Услуга: Способ предоставления ценности клиенту, через помощь в получении результата, которого хочет достичь пользователь, без несения специфических затрат и рисков. ИТ-услуга: услуга, предоставляемая провайдером ИТ-услуг. ИТ-услуга представляет собой комбинацию ИТ, людей и процессов. ИТ-услуга, предназначенная для клиента, непосредственно поддерживает бизнес-процессы одного или нескольких клиентов. Целевые параметры услуг, установленные клиентами, должны быть определены в соглашении об уровне услуг. Другие ИТуслуги, называемые поддерживающими услугами, не используются бизнесом непосредственно, но необходимы провайдеру услуг для оказания услуг клиентам. Ещё определения Управление услугами: Множество специализированных организационных способностей, необходимых для предоставления клиентам ценности в форме услуг. Провайдер услуг: Организация, поставляющая услуги одному или нескольким внутренним или внешним клиентам. Управление ИТ-услугами (ITSM): Реализация качественных ИТ-услуг, которые соответствуют потребностям бизнеса, и управление ими. Управление ИТ-услугами выполняется провайдерами ИТ-услуг через использование адекватного множества людей, процессов и информационных технологий. Провайдер ИТ-услуг: Провайдер услуг, который оказывает ИТ-услуги внутренним или внешним клиентам. И ещё … Соглашение об уровне услуг (Service Level Agreement, SLA): Используется, чтобы документирования соглашения между провайдером ИТ-услуг и клиентом. SLA описывает ИТ-услугу, документирует целевой уровень услуги и точно определяет ответственности провайдера ИТ-услуг и клиента. Одно соглашение может включать несколько ИТ-услуг или клиентов. Три типа провайдеров услуг в ITIL: тип 2 Объединение провайдеров Успешный провайдер услуг типа 2 может быть в состоянии оказывать своим услуги как внутренним, так и внешним клиентам. Это не сводится просто к предоставлению внешним клиентам уже имеющихся услуг. Стратегические решения и решения, связанные с корпоративным управлением, относятся к тому, как будет учитываться доход от услуг, будет ли ИТ-организация разделена на два подразделения, как она будет продавать свои услуги. Проблема в том, что, с одной стороны, должны достигаться первоначальные цели услуги, а с другой – внешние клиенты будут также претендовать на мощности, используемые услугой. Не стоит смешивать эту ситуацию с формальным объединением провайдеров, когда провайдеры сосуществуют внутри одной организации, и первый занимается обслуживанием своего бизнес-подразделения, а второй – предоставлением услуг внешним клиентам. Три типа провайдеров услуг в ITIL: тип 3 Внешние провайдеры Нужно иметь в виду, что организации, использующие внешних провайдеров, по-прежнему нуждаются в внутренней ИТ-функции для управления спецификациями услуг, координации контрактов и обеспечения желаемых бизнес-результатов. Внешние провайдеры работают в расширенной и более масштабной модели разделяемых услуг. Они подвержены большему риску со стороны клиентов, чем внутренние провайдеры. Но их способности и ресурсы разделяются их клиентами, которые могут быть и конкурентами. Это означает, что конкуренты получают доступ к одному и тому же набору активов, что нивелирует их конкурентные преимущества, связанные с этими активами. В то же время внешние провайдеры более свободны в выборе бизнеса, в котором они хотят участвовать.Они могут сужать или расширять портфель услуг по желанию и принимать решения об отказе от услуг определённого типа, или выбирать только определённый типами клиентов. Это позволяет им быть более гибкими и отказываться от рискованного бизнеса. Стратегия услуг (Service Strategy) Процессы стратегии услуг  Управление стратегией ИТ-услуг  Управление портфелем услуг  Управление финансами ИТ-услуг  Управление спросом  Управление взаимоотношениями с бизнесом Управление стратегией ИТ-услуг Что входит в стратегическое управление в ITIL Бизнес-стратегия • • • • • • • • • • Бизнес-тактика Как мы разрабатываем и поставляем продукты и предоставляем услуги? Как мы будем продавать продукты и услуги? Какие ресурсы и способности нам нужны? Как мы поддерживаем клиентов? Как мы управляем поставщиками? Как мы измеряем отдачу от инвестиций? • • • • • • Бизнес-операции • • • • • • Видение и миссия Цели Как цели будут достигнуты? Каковы наши приоритеты? Каков наш рынок? Кто наши клиенты? Какие продукты и услуги мы предлагаем? Как мы инвестируем? Организация и корпоративное управление Как мы будем улучшать наш бизнес? Создавать и поставлять продукты Предоставлять услуги Генерировать доход Управлять поставщиками Обрабатывать исключительные ситуации • • • • • • • • ИТ-стратегия (включая стратегию ИТ-услуг) Какие бизнес-результаты мы должны поддержать? Какие ИТ-услуги мы должны предложить, чтобы реализовать эти цели? Кто наши внутренние и внешние клиенты? Какие рыночные ниши мы обслуживаем? ИТ-стандарты Архитектура Как мы расставляем приоритеты и выбираем направления инвестиций? ИТ-организация и корпоративное управление Какими ограничениями мы должны управлять? ИТ-тактика услуг • • • • • • • • Как мы разрабатываем и предоставляем ИТ-услуги? Как мы управляем изменениями ИТ-услуг? Как мы используем ресурсы и способности? Как мы обеспечиваем доступность и эффективность ИТ-услуг? Как мы поддерживаем клиентов и пользователей? Как мы распоряжаемся инвестициями? Как мы находим возможности улучшения? Как мы управляем поставщиками? Операции для ИТ-услуг • Предоставлять ИТ-услуги • Управлять эффективностью и доступностью ИТ-услуг и поддерживающих их систем • Управлять инцидентами, проблемами и изменениями • Управлять ресурсами, необходимыми для разработки и предоставления услуг Стратегия организации с точки зрения ITIL Стратегия организации определяет её цели и то, как организация достигает этих целей, а также то, как организация узнаёт об их достижении. Без стратегии организация способна только реагировать на запросы различных стейкхолдеров и вряд ли может оценить влияние каждого запроса на организацию. В таких случаях действия организации управляются теми, чьи запросы «громче», а не тем, что лучше для самой организации. Стратегия становится функцией организационных политик и частных интересов, а не целенаправленным продвижением к поставленным целям. Точно определённая и правильно управляемая стратегия позволяет рационально использовать ресурсы и способности организации для достижения желаемых результатов и обеспечить соответствие инвестиций желаемым направлениям развития и роста. Стратегическое управление обеспечивает тот факт, что все стейкхолдеры принимают участие в выборе направления развития организации и все они согласны с её целями и методами выбора приоритетов использования ресурсов, способностей и инвестиций. Подразумеваемый жизненный цикл стратегии Разработка Согласование Исполнение Пересмотр Стратегия услуг в ITIL Стратегическое управление ИТ-услугами обеспечивает то, что портфель провайдера услуг состоит из нужных услуг, т.е., что все услуги провайдера имеют ясную цель и что каждый его сотрудник знает свою роль в достижении этой цели. Стратегическое управление ИТуслугами - это стратегическое управление для провайдера услуг. Сюда включаются определения всех типов оказываемых услуг, всех потребителей услуг и описание бизнесрезультатов, достигаемых в результате исполнения провайдером своей стратегии. Стратегия ИТ-услуг – подмножество ИТ-стратегии, которая, помимо стратегии ИТ-услуг, включает ещё стратегию ИТ-архитектуры, управление портфелем (отличным от портфеля услуг), управление приложениями, управление инфраструктурой, управление проектами, направления технологическое развитие и т.д. Стратегия отдельной услуги определяется в процессе управления портфелем услуг и документируется впортфеле услуг. Она включает описание бизнес-результатов, поддерживаемых услугой и способа предоставления услуги. Подразумеваемый жизненный цикл стратегии услуг Разработка портфеля услуг Согласование состава и условий предоставления услуг Предоставление услуг Пересмотр портфеля Как это работает на практике (ITIL) Для потребителя услуг стратегическое управление ИТ-услугами даёт возможность ясно формулировать его бизнес-приоритеты на языке, понятном провайдеру услуг. В некоторых случаях запрос пользователя может подразумевать отклонение от стратегии провайдера. Провайдер использует стратегическое управление услугами для принятия решения: изменить стратегию или отказаться от выполнения запроса? Если провайдер – внутренняя ИТ-организация, второй вариант может оказаться не всегда реализуемым, и в этом случае провайдер использует стратегическое управление услугами для того, чтобы довести до бизнес-подразделений информацию о влиянии их запросов на стратегию провайдера. Руководство бизнеса сможет после этого взаимодействовать с провайдером ИТ-услуг и выбрать вариант решения: изменить его стратегию или отклонить запрос. В других случаях запросы потребителей могут не изменять стратегию провайдера, но изменять его приоритеты. Стратегическое управление ИТ-услугами позволяет провайдеру найти лучший способ изменить приоритеты и сбалансировать ресурсы, способности и инвестиции. Управление портфелем услуг Решения, принимаемые провайдером с помощью портфеля услуг • Почему потребитель должен приобрести эти услуги? • Почему он должен приобрести эти услуги у нас? • Как устроены модель цены и схема взаиморасчётов? • В чём наши сильные и слабые стороны, приоритеты и риски? • Какие ресурсы и способности нам понадобятся? Что такое портфель услуг Портфель услуг – это полное множество услуг, которыми управляет провайдер услуг. Портфель используется для управления услугой на протяжении всего её жизненного цикла. Он включает три категории услуг: услуги из воронки услуг (предложенные или разрабатываемые услуги), услуги из каталога услуг (предоставляемые или готовые к внедрению услуги), устаревшие услуги. Портфель отражает инвестиции, сделанные в услуги, а также точно определяет ценность, которую помогают реализовать услуги. Управление портфелем услуг – это процесс, ответственный за отбор услуг для портфеля, и за то, как эти услуги будут отслеживаться и развиваться на протяжении их жизненного цикла Структура портфеля услуг Основные объекты портфеля услуг Воронка услуг Воронка услуг – это база данных или структурированный документ, содержащий все услуги, которые находятся в разработке или в рассмотрении , но пока недоступны потребителю. Она включает также связанные с услугами инвестиции, такие, как перемещение в другой датацентр, или проект визуализации. Это связано с тем, что инвестиции необходимо отслеживать вплоть до момента предоставления услуг и получения ценности, которую они приносят (провайдеру). Воронка включает возможные будущие услуги и является частью портфеля, обычно недоступной потребителям. Воронка характеризует общее «состояние здоровья» провайдера и показывает, насколько новые концепции услуг и идеи улучшения усваиваются в стратегии услуг, при проектировании и разработке услуг, в ходе непрерывного совершенствования услуг. Существует много причин попадания услуги в воронку, например: • клиент требует новой услуги, • стратегия провайдера выявила новую возможность, • клиент обнаружил новую бизнес-возможность, которая требует ИТ-поддержки, • бизнес-результат недостаточно поддержан текущими услугами, • появилась новая технология, которая может создать новые бизнес-возможности, • процесс управления услугами (напр.,управление мощностями, управление уровнем услуг или управление проблемами ) обнаружил лучшую реализацию существующей услуги, • процессы непрерывного улучшения услуг обнаружили разрыв в текущем портфеле услуг. Каталог услуг Каталог услуг – это база данных или структурированный документ, содержащий информацию обо всех действующих ИТ-услугах, включая услуги, доступные для развёртывания. Это единственная часть портфеля услуг, доступная потребителям. Они используется для продажи и предоставления услуг. Информация попадает в каталог только после того как будет выполнен анализ связанных с услугой затрат и рисков. Каталог – важный инструмент в стратегии услуг, поскольку он представляет текущие и реальные способности провайдера. Каталог используется как инструмент заказа и фиксации спроса на услуги. Он определяет политики, руководства и методы учёта, необходимые провайдеру для предоставления и поддержки услуг. Для каждой услуги в нём определены её компоненты, перечень связанных активов, процессов и систем, участвующих в услуге. Каталог играет роль портала продаж и включает цены, обязательства, условия предоставления услуг, методы запроса услуги и используемые для этого каналы коммуникаций. Каталог услуг Базы данных, приложения, серверы, сетевое оборудование … Поддерживающие услуги (напр., хостинг) невидимые для потребителя Пользовательские услуги Система управления конфигурациями Система управления конфигурациями (CMS) – это набор инструментов и баз данных, используемых для управления конфигурационными данными провайдера. CMS включает также информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах и может содержать данные о персонале, поставщиках, размещении офисов,бизнес-подразделениях, клиентах и пользователях. CMS включает инструменты сбора, хранения, управления и представления данных обо всех конфигурационных единицах и их взаимосвязях. CMS поддерживается процессом управления конфигурациями и используется всеми процессами управления ИТ-услугами. КБД – база данных управления конфигурациями, используется для хранения информации о конфигурации в течение всего её жизненного цикла. CMS поддерживает одну или несколько КБД. Каждая КБД хранит атрибуты конфигурационных единиц и их взаимосвязей. В контексте управления портфелем услуг CMS хранит данные о каждой услуге и конфигурационных единицах, составляющих услугу, людях и инструментах, поддерживающих услугу, и взаимосвязях между ними. Портфель услуг – это часть системы управления знаниями об услугах (SKMS), которая базируется на данных из источников, содержащихся в CMS. Портфель приложений Портфель приложений – это база данных или структурированный документ, использующийся для управления приложениями в течение их жизненного цикла. Он содержит ключевые атрибуты всех приложений. Иногда он реализуется как часть портфеля услуг, или, если портфеля услуг не существует - как часть системы управления знаниями об услугах (SKMS). Часто встречающаяся ошибка – использование портфеля приложений вместо портфеля услуг. Хотя все приложения представлены в портфеле услуг, они обычно не являются услугами. Например, одна услуга может использовать несколько приложений (прайс-лист компании извлекает данные из приложений, управляющих производством, складом, продажами и доставками). Наоборот, услуга может быть лишь одним из многих результатов работы приложения (приложения для расчёта зарплаты предоставляет несколько услуг: выплаты персоналу, генерацию налоговых отчётов и т.д., предоставляемых разным сотрудникам или группам сотрудников организации. Хотя в управление портфелем услуг не входит создание и поддержание портфеля приложений, там контролируется состав этого портфеля. Т.е., каждый элемент портфеля приложений должен быть связан с одним или несколькими элементами портфеля услуг. Портфель клиентов Портфель клиентов – это база данных или структурированный документ, использующийся для регистрации всех клиентов провайдера ИТ-услуг. Он представляет собой информацию менеджера по связям с бизнесом, касающуюся клиентов, получающих услуги провайдера. Управление портфелем услуг использует портфель клиентов для поддержки прозрачных связей между бизнес-результатами, клиентами, и услугами. Управление портфелем услуг документирует эти связи и согласует их с клиентами в процессе управления взаимодействием с бизнесом. Портфель клиентских контрактов Портфель клиентских контрактов – это база данных или структурированный документ, использующийся для управления контрактами на оказание услуг между провайдером ИТ-услуг и его клиентами. Хотя многие организации полагают, что контракт возникает только после подписания SLA, это не так. Всякий раз, когда провайдер предоставляет услугу, а клиент её потребляет, возникает контракт на оказание услуг. Проблема в том, что это неформальные контракты, вследствие чего возникают расхождения между ожиданиями клиента и услугой провайдера. Лучшие практики показали, что формальный подход, использующий SLA, помогает преодолеть эти трудности и контролировать изменение услуг в соответствии с изменяющимися бизнес-потребностями. Однако, если SLA не используются, необходимо, как минимум, формально задокументировать ожидания клиента, связав их с оказываемой услугой, а затем добиться того, чтобы клиент подписал документ. Внутренние провайдеры используют портфель контрактов для мониторинга SLA и менее формальных контрактов, чтобы иметь возможность контролировать ожидания клиентов или не допускать изменений ожиданий без дополнительного финансирования провайдера. Портфель проектов Портфель проектов – это база данных или структурированный документ, использующийся для управления проектами, для которых были утверждены уставы. Он позволяет координировать проекты, гарантируя достижение поставленных целей в рамках бюджетов и сроков проектов. Он не допускает дублирования проектов, контролирует соблюдение границ проектов и обеспечивает проекты ресурсами. Обычно портфель проектов создаётся и сопровождается проектным офисом бизнесорганизации. Он важен для управления портфелем услуг, потому что новые услуги и многие изменения действующих услуг реализуются как проекты. Основные шаги процесса управления портфелем услуг • Определить. Документировать и понять существующие и новые услуги. Каждая услуга должна иметь обоснование. • Проанализировать. Анализ услуг портфеля показывает, может ли услуга оптимизировать ценность, и как сбалансировать спрос и предложение. • Утвердить. Каждая услуга должна быть утверждена. Должен быть одобрен размер инвестиций для привлечения достаточных ресурсов, чтобы обеспечить необходимый уровень услуги. • Разработать устав. Услуги не создаются просто по запросу кого-либо в организации. Проекты должны иметь уставы, стейкхолдеры должны получать информацию о принимаемых решениях, ресурсах и сделанных инвестициях. Управление взаимоотношениями с бизнесом Определение Управление взаимоотношениями с бизнесом – это процесс, который обеспечивает менеджеров по взаимодействию с бизнесом возможностью устанавливать связи между провайдерами услуг и клиентами на стратегическом и тактическом уровнях. Эти связи устанавливаются для того, чтобы провайдер услуг понимал бизнес-требования клиентов и мог предоставлять соответствующие услуги. Главным показателем того, насколько этого удаётся достичь, является уровень удовлетворённости клиента. Цели процесса  Обеспечить понимание провайдером отношения клиентов к услугам, чтобы он мог правильно расставить приоритеты между услугами и их активами  Обеспечить высокий уровень удовлетворённости клиента и повышать ценность услуг  Установить и поддерживать конструктивные взаимоотношения между провайдером и клиентами на основе понимания бизнес-драйверов клиентов  Выявлять изменения окружения клиентов, которые могут повлиять на тип, уровень и степень использования услуг провайдера  Выявлять технологические тренды, которые потенциально могут повлиять на тип, уровень и степень использования услуг провайдера  Устанавливать и точно формулировать требования к новым и существущим услугам  Обеспечить удовлетворение провайдером потребностей клиента  Служить посредником в случае конфликта требований разных бизнесподразделений Типы провайдеров и управление взаимоотношениями  Для внутренних провайдеров управление взаимоотношениями обычно имеет место применительно к взаимодействию руководства ИТ-организации (крупные ИТ-организации могут иметь специальные роли менеджеров по взаимоотношениям с клиентами) и старшим менеджментом бизнесподразделений. Акцент здесь делается на соответствии целей бизнеса активностям провайдера услуг  Для внешних провайдеров управление взаимоотношениями часто поручается специальным эккаунт-менеджерам, каждый из которых работает с конкретным крупным клиентом или группой более мелких клиентов. Акцент здесь делается на максимизации ценности контракта для провайдера, которая является функцией удовлетворённости клиента Управление взаимоотношениями и управление уровнем услуг Управление взаимоотношениями Управление взаимоотношениями с бизнесом с бизнесом Назначение Фокус Главные метрики Управление уровнем услуг Управление уровнем услуг Установить и поддерживать отношения между провайдером и клиентом на основе понимания потребностей клиента. Идентифицировать необходимые полезность и гарантированность услуги и добиться того, чтобы провайдер смог их обеспечить. Провести с клиентом переговоры об условиях соглашения об уровне услуг (гарантированность) и добиться, чтобы SLA, OLA и UC соответствовали согласованным целевым уровням услуг. Стратегический и тактический – фокус на взаимоотношениях в целом и понимании того, какие услуги необходимы клиентам. Тактический и операционный – фокус на достижении соглашения об уровне, который необходим для новых и существующих услуг, и том, насколько провайдер способен достичь этого уровня. Удовлетворённость клиента, повышение готовности клиента использовать услугу и платить за неё. Оценка того, насколько клиенты готовы рекомендовать услугу другим (потенциальным) клиентам Достижение согласованных уровней услуг (что ведёт к удовлетворённости клиентов). Требования клиентов и пользователей различны Клиенты Пользователи Цена Насколько услуга затратна? Превосходит ли она с точки зрения затрат услуги других провайдеров? Как мы можем её удешевить? Эффективность Насколько услуга быстро работает? Каково время отклика? Всегда ли она доступна, когда нужна? Выгодность/Ценность Обеспечит ли услуга возврат инвестиций? Поможет ли она достичь наших бизнес-целей? Простота использования Насколько интуитивен пользовательский интерфейс? Сколько экранов мне нужно просмотреть, чтобы выполнить транзакцию? Обучат ли меня пользоваться услугой? Облегчит ли она мою работу? Эффект от услуги Что реально даёт услуга? Увеличит ли она продуктивность? Поможет ли она улучшить наши услуги? Где мы будет через полгода, год, три года использования услуги? Инновации Поможет ли эта услуга выявить новые возможности? Поможет ли она увеличить мой бизнес? Поможет ли она выйти на новые рынки? Или увеличить наше предложение? Качество Как на самом деле работает эта услуга? Делает ли она всё, что я хочу? Поможет ли она решить проблемы, с которыми я сталкиваюсь? Согласованность Смогу ли я пользоваться услугой всё время, пока я на работе? Всегда ли она работает одинаково? Выводы по стратегии услуг  ITIL пытается объединить подходы к стратегическому управлению ИТ-услугами для провайдеров всех типов  ITIL формулирует разницу между клиентами и пользователями, как в отношении потребляемых услуг, так и в возможности компенсировать усилия провайдера [получается, что провайдер только косвенно мотивирован оказывать услуги пользователям]  Основой при разработке услуг внутренних провайдеров служит стратегия бизнес-организации, согласованная руководителями бизнеса до начала работы над каталогом услуг [если стратегии нет, ITIL не даёт рекомендаций по тому, как развивать услуги]  Частота внесения изменений в каталог не оговаривается [непонятно, как изменения отражаются на бизнес-стратегии (и отражаются ли вообще)]  Поскольку внутренний провайдер – всегда центр затрат, единственный показатель его успешности – низкий уровень затрат [такие вопросы, как связь между уровнем затрат на ИТ и качеством услуг, из каких соображения повышаются уровни затрат и т.п., остаются неясными]  Не указаны владельцы процессов [вообще характерно для ITIL, где процессы и функции не различаются явно] Проектирование и разработка услуг (Service Design) Проектирование и разработка услуг Проектирование и разработка услуг – это часть более общего процесса изменения бизнеса. Диаграмма показывает поток активностей процесса изменений с точки зрения бизнеса – т.н. «процесс бизнес-изменений». Отдельные шаги процесса отражают тот факт, что со стороны бизнеса изменение чаще всего является изменением бизнес-процесса, которое и вызывает необходимость изменений ИТ-услуги. Как только будет известна и утверждена точная информация об изменении потребностей бизнеса, можно разработать план предоставления соответствующей услуги. Роль стадии проектирования и разработки услуг в рамках общего процесса изменений можно описать как проектирование и разработку инновационных ИТ-услуг, включая их архитектуры, процессы, политики и документацию. Границы проектирования и разработки услуг Основные аспекты проектирования и разработки услуг 1. Решения для новых или изменившихся услуг Требования новых услуг или изменений в существующих поступают из портфеля услуг. Каждое требование анализируется, документируется и согласуется. Затем разрабатывается решение для услуги. Оно должно соответствовать имеющимся стратегиям и ограничениям из стратегии услуг. Нужно также обеспечить совместимость новой или изменённой услуги с остальными услугами. Все услуги, взаимодействующие с этой услугой, или зависящие от неё, также должны быть приведены в соответствие с ней. Каждая новая разработка услуги рассматривается во взаимодействии с остальными четырьмя аспектами проектирования и разработки. Основные аспекты проектирования и разработки услуг 2. Информационные системы управления, инструменты Информационные системы управления и инструменты (SKMS, портфель услуг, каталог услуг) нужно проанализировать, чтобы убедиться, что они могут поддерживать новую или изменившуюся услугу. 3. Технологические архитектуры и архитектуры управления Эти архитектуры анализируются для того, чтобы гарантировать, чтоб они совместимы с новой или изменённой услугой и могут исполнять и поддерживать новую услугу. В противном случае нужно либо откорректировать их, либо пересмотреть разработанную услугу. Основные аспекты проектирования и разработки услуг 4. Процессы Процессы анализируются для того, чтобы убедиться, что они, включая роли, ответственности и умения, могут выполнять и поддерживать новую или изменённую услугу. В противном случае нужно пересмотреть услугу или расширить возможности существующего процесса, включая процессы управления ИТ, процессы управления услугами, а не только процессы стадии проектирования и разработки услуг. 5. Методы измерения и метрики Они должны быть проанализированы для того, чтобы гарантировать, что существующие методы измерений могут поддержать требуемые метрики, касающиеся новых и изменённых услуг. В противном случае, нужно или расширить методы измерений, или пересмотреть состав метрик. Из чего состоит услуга Как синхронизировать проектирование и разработку с потребностями бизнеса Для того, чтобы синхронизировать бизнес и ИТ-услуги, многие компании создают комитеты, состоящие из руководителей бизнеса и ИТ-службы. Такой комитет берёт на себя полную ответственность за организацию корпоративного управления, определение направления развития, политик и стратегии ИТ-услуг, которые Функция такого комитета – служить партнёром и посредником ИТ-организации и бизнеса. Он должен периодически анализировать бизнес- и ИТ-стратегии, разработки, планы, портфель услуг, архитектуры и политики для того, чтобы гарантировать, что они соответствуют друг другу. Он должен определять общее видение, направление и приоритеты отдельных программ, чтобы ИТ были согласованы с бизнесом и служили достижению его целей. Взаимосвязи и зависимости ИТ-услуг Жизненный цикл услуги Аббревиатуры SAC (Service Acceptance Criteria) – критерий приёмки услуги, используется для того, чтобы гарантировать, что провайдер услуги готов предоставлять и поддерживать новую или изменённую услугу в рабочей среде. Результатом проектирования и разработки услуг является т.н. пакет услуги (Service Design Package, SDP), который позволяет построить, протестировать и запустить активности стадии подготовки и развёртывания услуги, а также активности исполнения, сопровождения и улучшения стадии операций и непрерывного улучшения услуг. Процессы проектирования и разработки 1. Координация проектирования (Design Coordination). Этот процесс обеспечивает единую точку координации и управления всеми активностями и процессами на протяжении всей фазы проектирования услуги. 2. Управление Каталогом услуг (Service Catalogue Management). Процесс порождает и поддерживает Каталог услуг, обеспечивая точность содержащейся в нём информации о действующих услугах и услугах, готовящихся к вводу в действие. 3. Управление уровнем услуг (Service Level Management). В этом процессе происходит согласование целей ИТ-услуг с представителями бизнеса . Затем организуется оперативный контроль за предоставляемыми услугами, чтобы гарантировать соответствие их согласованным целям. 4. Управление мощностями (Capacity Management). Процесс обеспечивает своевременное наличие всех мощностей, относящихся к ИТ и соответствующих текущим и будущим потребностям бизнеса 5. Управление доступностью (Availability Management). Процесс обеспечивает то, что в каждый момент времени уровень доступности всех услуг точно соответствует текущим и будущим потребностям бизнеса или превосходит их. Процессы проектирования и разработки 6. Управление непрерывностью ИТ-услуг (IT Service Continuity Management). Процесс направлен на то, чтобы работоспособность всего необходимого оборудования (включая компьютерные системы, сети, приложения, репозитории данных, телекоммуникации, среду, техподдержку и службу Service Desk) всегда могла быть восстановлена в согласованные с бизнесом сроки. 7. Управление информационной безопасностью (Information Security Management). Процесс устанавливает уровень ИТ-безопасности, соответствующий уровню бизнес-безопасности, и гарантирует эффективное управление безопасностью во всех услугах и процессах управления услугами. 8. Управление поставщиками (Supplier Management). Процесс управляет поставщиками и предоставляемыми ими услугами, обеспечивая одинаковый уровень качества всех ИТ-услуг для бизнеса. Процессы проектирования и разработки Выводы по проектированию и разработке услуг  ITIL не включает в управление проектированием и разработкой процессы управления жизненным циклом систем, управления проектами, управления процессами, обучения и др. [что, возможно, связано со значительным объёмом других источников, затрагивающих эти вопросы]  ITIL трактует SLA как соглашение, только фиксирующее договорённости [никаких методов стимулирования выполнения условий SLA, как и наказаний за его невыполнение не предусматривается]  Управление изменениями в системе соглашений и контрактов устроено очень примитивно [изменения обрабатываются пакетами в заранее согласованные даты]  Управление внешними поставщиками описано на самом общем уровне и не содержит никакой специфики, ни относящейся к услугам, ни связанной с ИТ.  Тип соглашения с внешними поставщиками (это всегда контракт) не зависит от соответствующего SLA [тем самым поставщики-партнёры не допускаются] Предоставление услуг (Service Operation) Что такое предоставление услуг Назначение стадии предоставления услуг – координация и выполнение активностей и процессов, необходимых для оказания услуг и управления ими в соответствии с согласованными уровнями услуг. Предоставление услуг ответственно также за оперативное управление технологиями, использующимися при оказании и поддержке услуг. Персонал, занятый на этой стадии, должен располагать процессами и инструментами поддержки, которые позволили бы реализовать общий взгляд на предоставление услуг и диагностировать угрозы или провалы в качестве услуг. Поскольку услуги могут полностью или отчасти предоставляться внешними поставщиками, услуга с точки зрения стадии предоставления услуг должна восприниматься как кросс-организационный объект, для управления которым должны использоваться сквозные процессы. Процессы предоставления услуг  Управление событиями. Управляет событиями на протяжении их жизненного цикла, который включает координацию активностей для распознавания события, осмысление события, принятие мер по событию.  Управление инцидентами. По возможности быстрое восстановление работоспособности неожиданно отказавших или деградировавших услуг.  Выполнение запросов. Управление жизненным циклом всех запросов услуг с момента возникновения до выполнения. Запросы регистрируются отдельно, их статусы отслеживаются. Запросы – это формальный механизм общения пользователей с провайдером, предоставляющим стандартные услуги. С ними связаны модели запросов, определяющие пререквизиты, согласования и стандартные шаги и активности, предпринимаемые для выполнения запроса. Среди таких шагов – стандартные изменения и другие типы запросов на изменения (Requests for Change, RFCs) Процессы предоставления услуг  Управление доступом. Предоставление пользователям прав доступа к услугам. Основан на тщательном определении того, какие роли и должности сотрудников требуют доступа к определённым услугам. Называется также управлением организационными полномочиями (Identity management) или управлением организационными правами (Right management). Поддерживает политики, определённые в процессе управления информационной безопасностью.  Управление проблемами. Выяснение и устранение скрытых причин инцидентов и проактивные действия по предупреждению будущих проблем/инцидентов. Регистрация известных ошибок и обходных путей для быстрого разрешения инцидентов и проблем в будущем. Услуги, запросы услуг, модели запросов и запросы на изменение Функции предоставления услуг Только процессов недостаточно для продуктивного предоставления услуг. Необходимы также устойчивая инфраструктура и обученный персонал. В предоставлении услуг это достигается за счёт нескольких функций, реализующихся в ходе выполнения операционных задач. Функции – это группы обученных сотрудников, которые выполняют оlин или несколько процессов и активностей жизненного цикла услуг. Функции предоставления услуг Сервис деск. Это единственная точка контакта для пользователей при прерывании услуги для подачи запроса услуги или даже определённых RFC. Сервис деск представляет собой точку коммуникации для пользователей и точку координации для некоторых ИТ-групп и процессов. Техническое управление. Предоставляет технические знания и ресурсы, необходимые для операционной поддержки предоставления ИТ-услуг и управления ИТ-инфраструктурой. Играет важную роль в проектировании и разработке, улучшении и выпуске релизов ИТ-услуг. Функции предоставления услуг  Операционное управление ИТ. Выполняет ежедневные работы по управлению ИТ-услугами и поддержке ИТ-инфраструктуры. Использует стандарты эффективности, заданные при проектировании услуг. В некоторых организациях этим занимается централизованный департамент, в других – персонал может привлекаться из разных департаментов. Операционное управление ИТ имеет две подфункции:  операционный контроль ИТ. Это персонал, работающий посменно и выполняющий рутинные операции. Обеспечивает централизованный мониторинг, обычно используя автоматизированные средства сбора информации о событиях,  управление средой. Это управление физической средой, обычно датацентрами или компьютерными залами. Функции предоставления услуг Управление приложениями. Отвечает за управление приложениями на протяжении всего их жизненного цикла. Поддерживает и сопровождает действующие приложения, а также играет важную роль в проектировании и разработке, тестировании и модификации приложений, входящих в ИТ-услуги. В ITIL управление приложениями отличается от создания приложений. Создание приложений обычно относится к приложениям, разработанным внутри ИТорганизации. Контекст управления приложениями значительно шире, включая анализ состояния рынка с целью поиска нужных приложений из разных источников. Кроме этого, выполняются операционное управление и сопровождение развёрнутых приложений. Функции предоставления услуг Примеры того, что включает контекст управления приложениями:  приложения, разработанные внутри ИТ-организации,  приложения, приобретённые у третьих сторон, или разработанные на заказ,  облачные приложения, такие, как SaaS-решения,  сопровождение приложений и другие работы по управлению приложениями,  апгрейды приложений,  лицензирование приложений и контроль за законностью их использования,  соответствие приложений другим отраслевым требованиям, таким, как специальные средства контроля, отраслевые стандарты или требования, связанные с использованием людьми с ограниченными возможностями,  гарантийные обязательства, обеспечивающие использование приложений с приемлемыми уровнями затрат и риска. Управление событиями События Событие – это любое изменение состояния, имеющее значение для управления конфигурационной единицей или ИТ-услугой. Обычно о событиях узнают через уведомления, которые порождаются услугой, КЕ или инструментом мониторинга состояния. Возможность продуктивно управлять услугами зависит от статуса инфраструктуры и возможности распознавать отклонения от её нормального или ожидаемого состояния. Для мониторинга состояния используются два типа инструментов:  инструменты активного мониторинга, опрашивающие ключевые КЕ, чтобы определить их статус и доступность. Об исключительных ситуациях уведомляются соответствующие системы или команды людей,  инструменты пассивного мониторинга, распознающие и объединяющие уведомления или сообщения, порождаемые КЕ. Где применяется управление событиями Управление событиями применяется в разных ситуация, связанных с управлением услугами, когда требуются контроль и применимы автоматизированные средства:  для некоторых КЕ требуется, чтобы они постоянно находились в стабильном состоянии (например, сетевые переключатели должны быть постоянно включены), и средства управления событиями подтверждают это, опрашивая их,  некоторые КЕ часто изменяют состояние, и управление событиями используется для автоматизации переключений и обновления системы управления конфигурацией (например, при обновлении файл-сервера),  нужно контролировать данные системы пожарной сигнализации,  нужно мониторить состояние лицензий на ПО для оптимизации лицензирования,  нужно следить за безопасностью (например, за датчиками проникновения),  нужно отслеживать использование приложений и производительность серверов. Отбор событий Один из важнейших принципов управления событиями – правильный отбор наиболее значимых событий. Ситуация усложняется тем, что значимость событий изменяется. Например, сегодня доступ пользователя к системе – обычное событие, а завтра, если пользователь покинул организацию, становится попыткой нарушения правил безопасности. Существует несколько стратегий отбора. Интеграция. Интегрируйте управление событиями во все процессы управления услугами, когда это имеет смысл. В результате будут отобраны только те события, которые значимы для этих процессов. Отбор на стадии проектирования. Проектируйте новые услуги, помня об управлении событиями. Отбор событий Отбор путём проб и ошибок. Независимо от того, насколько тщательно построено управление событиями, будут существовать классы событий, отобранных неточно или неправильно. Управление событиями должно поэтому включать формальный процесс оценки правильности отбора. Отбор при планировании. Планирование нужно при развёртывании ПО управления событиями в масштабах всей ИТ-инфраструктуры. Это проект, и необходимые для него ресурсы должны быть закреплены за ним в течение всего хода проекта. Наборы правил и объединение событий Набор правил определяет как обрабатываются и оцениваются сообщения о конкретном событии. Например, предупреждающее сообщение может генерироваться каждый раз, когда журнал (log file) диска достигает максимального размера, но исключительная ситуация возникнет лишь тогда, когда предупреждающее сообщение будет сгенерировано более четырёх раз. Правила обычно встроены в технологии и методы мониторинга и обработки событий. Они состоят из алгоритмов логического объединения возникших событий, порождающих новые события, которые и распространяются далее. Эти алгоритмы в составе ПО управления событиями называют механизмами объединения (correlation engines) Управление инцидентами Что такое управление инцидентами? В терминологии ITIL инцидент – это внеплановое прерывание ИТ-услуги или падение качества ИТ-услуги или отказ КЕ, который ещё не успел сказаться на услуге (например, отказ одного из дисков, входящих в зеркало сайта). Управление инцидентами – это процесс, ответственный за управление жизненным циклом инцидентов. Инциденты могут распознаваться ИТ-специалистами, регистрироваться средствами мониторинга, поступать от пользователей (обычно по телефону сервис-деска) или от внешних поставщиков и партнёров. Назначение управления инцидентами Назначение управления инцидентами – скорейшее восстановление нормального обслуживания и минимизация негативного влияния инцидента на бизнес-операции, что обеспечивает согласованный уровень услуги. «Нормальное обслуживание» определяется как состояние, при котором услуги и конфигурационные единицы работают в соответствии с согласованными уровнями услуг (SLA) и операций (OLA). События, запросы услуг и инциденты Управление инцидентами включает все события, которые нарушают или могут нарушить нормальное предоставление услуги. Сюда входят события, о которых сообщают пользователи через сервис-деск или через интерфейс между управлением событиями и инструментами управления инцидентами. Об инцидентах может сообщать техперсонал (например, он может информировать сервис-деск о неполадках оборудования или сетевых устройств). Не все события являются инцидентами. Множество событий не нарушает обслуживания, а сигнализирует о нормальном функционировании и служат только для информирования. Хотя и события и запросы услуг направляются в сервис-деск, это не означает, что они тождественны. Запросы услуг не говорят о нарушении предоставления услуг, а служат только для взаимодействия с клиентом. Они могут ссылаться на согласованные целевые показатели в SLA. Запросы услуг обрабатываются процессом обработки запросов. Основные принципы управления инцидентами Время обработки инцидентов Время выполнения должно быть согласовано для каждого этапа обработки инцидента (в зависимости от приоритета инцидента). Оно должно учитывать общее время реакции на инцидент и целевые показатели из SLA, а также соответствующих OLA и UC. Все группы поддержки должны точно знать это время. Для учёта времени нужно использовать инструменты управления услугами и эскалировать инцидент в соответствии с предопределёнными правилами. Модели инцидентов Многие инциденты не являются новыми – они включают то, что уже случалось ранее и может произойти вновь. Поэтому многие организации определяют «стандартные» модели инцидентов и применяют их к соответствующим инцидентам. Основные принципы управления инцидентами Серьёзные инциденты Отдельный процесс, работающий в более сжатые сроки и использующийся в срочных случаях используется для «серьёзных» инцидентов. Определения серьёзных инцидентов в идеале должны быть заранее включены в схему расстановки приоритетов. При необходимости процедура обработки серьёзного инцидента может включать создание специальной команды для обработки инцидента под руководством менеджера инцидента. Последний занят исключительно конкретным инцидентом и отвечает за то, чтобы решение было найдено как можно быстрее. Если менеджером инцидентов является менеджер сервис-деска (например, в небольших организациях), то необходимо назначить отдельного человека на роль лидера команды по анализу инцидента, чтобы избежать конфликта интересов. Основные принципы управления инцидентами Отслеживание статуса инцидента Инциденты необходимо отслеживать на протяжении всего их жизненного цикла. В системе управления инцидентами последним присваиваются статусы, обозначающие их место внутри жизненного цикла.  Открыт. Инцидент распознан, но ресурсы для его разрешения пока не назначены.  В работе. Инцидент в процессе исследования и разрешения.  Разрешён. Решение для инцидента найдено, но процесс оказания услуги не проверен бизнесом или конечным пользователем.  Закрыт. Пользователь или бизнес согласовал решение и процесс предоставления услуги. Непрерывное улучшение услуг (Continual Service Improvement) Основной принцип Фундаментальным является принцип владения стратегией улучшения. Залогом успешной её реализации является существование отдельного менеджера (CSI Manager), ответственного за то, что организация использует и поддерживает лучшие практики улучшения. Менеджер по улучшению – основной защитник процессов улучшения и владелец всех проблем, связанных с улучшением. Он отвечает за успех CSI в организации. Его ответственность не сводится только к обеспечению лучших практик, но включает выделение ресурсов (людей и технологий), мониторинг, анализ, оценку трендов, отчётность и проектные активности. Менеджер по улучшению не отвечает за улучшение отдельных услуг. Это зона ответственности соответствующих владельцев услуг, работающих в принятой в организации концепции CSI. Семь шагов процесса непрерывного улучшения Методы непрерывного улучшения Оценка: варианты Только процессы Оценка только атрибутов процессов, основанная на общих принципах и указаниях, содержащихся в модели процессов Люди, процессы и технология Расширяет оценку процессов, включая оценку оргструктуры, навыков и знаний, ролей и талантов менеджеров и специалистов, вовлечённых в процесс, а также способность существующей технологии поддержки процессов поддерживать цели и переходные состояния процессов, Оценка: варианты Полная оценка Включает дополнительно к перечисленному оценку культуры восприятия в организации, способность организации вырабатывать стратегию процессов, структуру и функции процессной организации, способность руководить процессами для достижения целей процессов, оценку соответствия ИТ интересам бизнеса (business/IT alignment) с помощью процессных методик (frameworks), оценку эффективности процессных метрик/отчётов, оценку возможностей и распространённости практик, принятия решений, касающихся улучшения процессов со временем. Оценка процессов Уровни возможностей процессов Незавершенный (incomplete) процесс – это процесс, который, либо не выполняется, либо выполняется только частично. Одна или больше специфичных целей процессной области не удовлетворяется. Общих целей на этом уровне не существует. Процесс уровня возможностей 1 называется выполняемым (performed). Выполняемый 1 процесс – это процесс, который производит всю работу, необходимую для получения продуктов работ; специфические цели достигаются. Хотя уровень возможностей 1 означает существенные улучшения, эти улучшения могут быть утрачены со временем, если они не закреплены. Применение закрепления (общие практики CMMI с уровней развитости 2 и 3) помогает обеспечить поддержку улучшений. Процесс уровня возможностей 3 называется управляемым (managed) процессом. Управляемый процесс – это выполняемый процесс, который планируется и выполняется в 2 соответствии с политиками; используется квалифицированный персонал, располагающий необходимыми ресурсами для получения нужных выходов; необходимые стейкхолдеры включены в процесс; процесс мониторится, управляется и анализируется, а также сопоставляется с описанием. 170 Уровни возможностей процессов Процесс уровня 3 – это управляемый процесс, выкроенный из множества стандартных процессов организации в соответствии с корпоративной методикой; он имеет поддерживаемое описание процесса и вносит вклад в виде своего опыта в организационные процессные активы. Такой процесс называется определённым 3 (defined). Ключевое различие между уровнями 2 и 3 состоит в области охвата стандартов, описаний процессов и процедур. На уровне 2 они могут быть разными для каждого экземпляра процесса (например, в каждом проекте). На уровне 3 стандарты, описания процессов и процедуры выкраиваются из множества стандартных процессов для того, чтобы стать частью процессов проекта или организационной единицы; следовательно, они более целостны, если не считать различий, допустимых процедурами выкраивания. 171 Уровни зрелости организации На уровне зрелости 4 организация и проектные команды устанавливают числовые цели в отношении качества и производительности процессов и используют их как критерии при управлении процессами. Числовые цели основываются на потребностях клиентов, конечных пользователей, организации и ответственных за реализацию процессов. Качество и 4 производительность процесса понимаются статистически; управление ими происходит на протяжении жизненных циклов проектов. Принципиальное различие между уровнями зрелости 3 и 4 состоит в предсказуемости производительности процесса. На уровне 4 производительность проектов и процессов контролируется с помощью количественных методов и прогнозы базируются на статистическом анализе детальных данных процессов. 172 Уровни зрелости организации На уровне 5 организация постоянно улучшает свои процессы, используя количественное понимание бизнес-целей и потребностей в производительности. Уровень 5 предполагает улучшение процессов инкрементным путём технологических улучшений и инноваций. Сформулированы цели организации в области качества и производительности процессов, они пересматриваются, чтобы отразить меняющиеся 5 цели бизнеса, и используются при управлении улучшением процессов. Эффект предпринятых улучшений измеряется количественно и сравнивается с целями в области качества и производительности. Принципиальное отличие уровня 5 от уровня 4 – это фокус на управлении производительностью организации и её улучшении. На уровне 4 проектные команды и организация в целом понимают и контролируют производительность на уровне процессов. На уровне 5 организация управляет производительностью глобально, используя данные, собранные из разных проектов. 173 Измерение услуг  Анализ причин  Определить, в чём выражается успех, чего мы хотим достичь и как мы узнаем, что мы этого достигли?  Построение системы измерений и выбор метрик  Что нужно измерить, чтобы получить полезную информацию, которая позволит принимать стратегические, тактические и/или оперативные решения?  Какие метрики обеспечат необходимые данные и информацию?  Установить целевые значения для всех метрик при помощи SLA или целевых уровней услуг, согласованных внутри ИТ-службы  Критические характеристики системы измерения услуг:  Интегрированность в процесс бизнес-планирования  Фокус на целях бизнеса и ИТ-целях  Низкие затраты на измерения  Сбалансированность в выборе измеряемых величин  Способность к изменениям Измерение услуг  Измерения должны быть:  привязанными к времени  точными и надёжными  аккуратно определёнными, конкретными и ясными  адекватными с точки зрения целей  не вызывающими негативного поведения  направленными на улучшение  Роли и ответственности  Кто определяет метрики и целевые значения  Кто наблюдает и измеряет?  Кто собирает данные?  Кто обрабатывает и анализирует данные?  Кто готовит отчёты?  Кто представляет отчёты? Полная иерархия измерений Выбор метрик для расчёта KPI Качественные метрики   КФУ: повысить качество ИТ-услуг KPI: повысить рейтинг удовлетворённости клиентов на 10% в течение следующих шести месяцев Требуемые метрики  Начальная оценка удовлетворённости обработкой инцидентов  Заключительная оценка удовлетворённости обработкой инцидентов Измерения  Оценки отчёта об услугах в части обработки инцидентов  Доля оценок, посвящённых обработке инцидентов, в отчёте об услугах Выбор метрик для расчёта KPI Количественные метрики КФУ: Снижение затрат на ИТ KPI: Снижение затрат на обработку инцидентов с принтерами на 10%. Требуемые метрики:  Начальные затраты на обработку инцидентов с принтерами  Заключительные затраты на обработку инцидентов с принтерами  Затраты на улучшение ситуации Измерения:  Время, затраченное на обработку инцидентов персоналом первого уровня, и ср. зарплата  Время, затраченное на обработку инцидентов персоналом второго уровня, и ср. зарплата  Время, затраченное на решение проблем персоналом второго уровня, и ср. зарплата  Время, затраченное на обучение обходным решениям персонала первого уровня  Затраты на обращение за услугой к внешнему поставщику  Фактические трудозатраты внешнего поставщика Как выбирать KPI  Что KPI на самом деле говорит о достижении цели? Если целевое значение KPI не будет достигнуто, будет ли это означать, что некоторые цели не достигнуты (и наоборот)?  Насколько просто интерпретировать KPI? Помогает ли он принимать решения?  Когда необходима информация? Как часто? Как быстро она должна быть доступна?  Насколько KPI стабилен и точен? Зависит ли он от внешних, неконтролируемых влияний? Каков объём усилий по изменению результатов?  Насколько просто изменить сам индикатор? Легко ли адаптировать систему измерений к изменившимся обстоятельствам или к изменениям наших целей предоставления ИТ-услуг?  Насколько KPI измерим сейчас? При каких условиях можно продолжать измерения? Что мешает измерениям? Что может сделать результат измерения бессмысленным?  Кто владелец KPI? Кто отвечает за сбор и анализ данных? За улучшения? Метрики баланса Усилия любой команды поддержки зависят от трёх элементов:  Ресурсы – люди и деньги  Функциональность – продукт или услуга и его/её качество  График Продукт/услуга поэтому представляют собой сбалансированный компромисс между этими элементами. Метрики баланса помогают избежать концентрации на одном элементе, например, на предоставлении продукта/услуги вовремя. Это может привести либо к возрастанию затрат, либо к снижению качества. Метрики баланса можно рассматривать как инструмент разделения ответственности между участниками команды на протяжении жизненного цикла услуги. Пример метрик баланса Организация может сфокусироваться на количестве инцидентов, обрабатываемых каждым сотрудником сервис-деска, но игнорировать процент успешно разрешенных инцидентов. Если этот процент снижается из-за того, что персонал стремится «поучаствовать» в обработке большего числа инцидентов, то итоговое качество услуги будет снижаться. В этом случае метриками баланса будут «число инцидентов, обработанных каждым сотрудником сервис-деска» и «процент успешно разрешенных инцидентов». Эти метрики необходимо рассматривать совместно. Интерпретация измерений Простое наблюдение результатов и непосредственное истолкование тренда могут оказаться неверными. Видя, что сервис-деск открывает меньше и меньше инцидентов за последние месяцы, можно сделать разные выводы. Это может происходить потому, что инцидентов действительно стало меньше, а может быть, потому, что пользователи не удовлетворены услугой и ищут других способ её улучшения. Возможно, организация реализовала базу знаний и некоторые пользователи стали пользоваться ею вместо обращения в сервис-деск. Правильная интерпретация, возможно, будет получена, если удастся понять, произошли ли какие-то изменения в услуге, или задаться вопросом о других объяснениях существующей ситуации. Пример интерпретации Стоит задаться следующими вопросами: • Из-за чего упало число инцидентов? • Что повиляло на нашу способность восстановить услугу при первом обращении? • Нанимали ли мы новых аналитиков в сервис-деск? • Удалялись ли какие-нибудь услуги? • Не были ли предоставлены другие средства оценки услуг? • Не были ли реализованы другие процессы, повлиявшие на ситуацию? Выводы по ITIL v.2011  ITIL даёт комплексный и целостный взгляд на управление ИТ-услугами, т.е., фактически на ИТ-менеджмент  ITIL, по-видимому, рассчитан в большей степени на теоретическое изучение и осмысление ИТ-менеджмента (студенты, консультанты), а не на специалистовпрактиков  Уровень изложения в ITIL не очень детальный, изложение избегает технических деталей и концентрируется на проблемах управления  ITIL не предлагает радикальных улучшений или новых решений, а систематизирует накопленный опыт и объединяет существующие методики в рамках единой концепции управления ИТ-услугами  ITIL придерживается консервативного традиционного подхода к стратегическому планированию ИТ, управлению изменениями, непрерывному улучшению Система управления услугами