Введение в ITSM (ITIL v.3) Андрей Кочуков. ISS-advance (Киев)

История ITIL ITIL- IT Infrastructure LibraryITIL- IT Infrastructure Library Существует с 80-х годов прошлого века Существует с 80-х годов прошлого века Издается британским правительственным агентством (OGC)Издается британским правительственным агентством (OGC) Библиотека передового опыта по предоставлению ИТ-CервисовБиблиотека передового опыта по предоставлению ИТ-Cервисов

5 томов ITIL v.3 Service Strategy (выработка стратегии). Service Design (создание услуги). Service Transition (подготовка услуги к операционному использованию). Service Operation (операционное использование). Continual Service Improvement (непрерывное улучшение услуги).

Вместе с ITIL Обучение Сертификация Консалтинг Программное обеспечение Сообщество

MOF

MOF v.4

HP ITSM reference model

IBM IT process model

Цикл управления качеством

IT как полноправный партнер бизнеса 10 Управление Cервисами Поддержка Cервисов Предоставление Cервисов Управление приложениями Управление безопасностью Управление ICT инфраструктурой Внедрение управления Cервисами Бизнес Технология С точки зрения бизнеса

Подходы в управлении Функциональный – каждому сотруднику соответствует его функция Функциональный – каждому сотруднику соответствует его функция Проектный – создается временная команда проекта Проектный – создается временная команда проекта Процессный - ролевая модель управления Процессный - ролевая модель управления

Понятие процесса Совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы (ISO 9000:2001)

Уровни зрелости процессов – 0 Отсутствующий – 1 Начальный – 2 Повторяемый – 3 Определенный – 4 Управляемый – 5 Оптимизируемый

Управление процессом Менеджер процесса Владелец процесса

Идеология ITIL v.3

Стратегия сервисов Формирование стратегии Управление Финансами Управление портфелем сервисов Управление требованиями

Формирование стратегии Атрибуты описания сервиса Атрибуты описания экземпляра сервиса КатегорияЦенаОпции Процедура запроса сервиса Утверждающие лица SLA на сервис Статус жизненного цикла сервиса Связанные CI ИзмененияИнциденты Остановки в работе сервиса, история Метрики SLA Связи с пользователями через индивидуальную подписку Связи с департаментами через коллективную подписку

Жизненный цикл сервисов

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

Управление требованиями Demand management критический аспект управления уровнем сервиса. Цель Demand Management: определение влияния требований заказчика к предоставляемым сервисам, мощностям и оборудованию для обеспечения требований. На стратегическом уровне включает в себя анализ модели бизнес и пользовательских активностей. На тактическом уровне, привлечение к использованию различных методов для заинтересованности пользователей к уменьшению использования IT сервисов в тот момент когда ресурсы IT заняты. Service Level Package (SLP) определяет уровень полезности и гарантий для Пакета Сервисов и построен для достижения нужд учитывая характер бизнес активностей.

Поддержка Сервисов Моделирование сервисов Создание и визуализация связей между ИТ-системами и конфигурационными единицами, формирующими сервис. Публикация описаний сервисов в Каталоге сервисов. Определение поддерживаемого уровня сервисов. Настройка функции запроса сервисов. Исполнение запросов на сервисы. Отслеживание жизненного цикла предоставляемых сервисов. Мониторинг работоспособности ИТ-компонентов и поддержка сервисов. Измерение и анализ параметров предоставления сервисов. Оптимизация (модернизация) сервисов.

Финансовый менеджмент Цель: обеспечить надежную финансовую основу деятельности по предоставлению ИТ-СервисовЦель: обеспечить надежную финансовую основу деятельности по предоставлению ИТ-Сервисов Обычно рассматривается как совокупность трех процессов:Обычно рассматривается как совокупность трех процессов: БюджетированиеБюджетирование Учет затрат (Accounting)Учет затрат (Accounting) Возмещение затрат (Charging)Возмещение затрат (Charging)

Бюджетирование – Позволяет планкровать потребность в деньгах – Дает возможность сравнить план и факт – Снижает риск излишних затрат – Гарантирует, что доходы достаточны

Учет затрат – Позволяет определить – Себестоимость Сервисов – Себестоимость Изменений – Позволяет делать анализ затрат

Модель затрат Элементы затрат HWSWHRПрочие ПравовикиКадры Прямые затраты ПоглощаемыеНепоглощаемые Непрямые затраты Прямые + поглощаемые затраты Непоглощаемые затраты полностью и максимально справедливо делятся между всеми получателями Сервиса.

За что и сколько? Необходимо определить:Необходимо определить: – Единицу оплаты – Стоимость услуг по себестоимости по себестоимости фиксированная наценка фиксированная наценка аналогичная цена аналогичная цена договорная цена договорная цена рыночная цена рыночная цена

Рекомендация Точно учитывать затраты для поддержки принятия решений (окупается ли предоставление данного Сервиса), но оценивать предоставление Сервиса в зависимости от его оговоренного уровня

Типы сервис провайдеров ТипI: организация предоставляет сервис исключительно для одного бизнес- подразделения Тип II: Обслуживание нескольких бизнес подразделений внутри одной организации Тип III: аутсорсинговая сервисная организация предоставляет сервис внешним заказчиках

Управление портфелем сервисов Service Portfolio Management (SPM) Определение: инвентаризация сервисов, обеспечение выполнения бизнес задач и подтверждение актуальности данных из портфеля услуг Анализ: повышения стоимости портфеля услуг, выстраивание и приоритизация на основе спроса и предложения Одобрение: окончательное подтверждение предложенного портфеля услуг, авторизация сервисов и выделенных ресурсов Подписание документа: сообщение решений, распределение ресурсов и предоставление сервисов.

Схема управления портфелем сервисов

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

Ключевые принципы дизайна сервисов 5 индивидуальных аспектов Дизайна Сервисов: Новые или измененные сервисы Система управления сервисами и инструменты сервисов, отображенных в Портфеле сервисов Технологическое обеспечение управления сервисами Процессы, роли и соответствия Методы измерения и метрики.

Место дизайна сервисов в жизненном цикле

Управление каталогом услуг Цели создания каталога услуг: Переход на сервисно - ориентированную модель Прозрачность предоставления IT услуг Улучшение взаимодействия с потребителями услуг Построение долгосрочных отношений между IT и бизнесом Управление издержками на обслуживание

Этапы проекта внедрения каталога услуг Создание «внутреннего каталога» Создание каталога для бизнеса Создание каталога для пользователей Рекомендация: Каталог услуг должен состоять из перечня услуг с указанием ценности для бизнеса и стоимости каждой услуги На первом этапе может быть согласован в неофициальной форме.

Управление Доступностью Цель: определять требуемый бизнесу уровень Доступности и обеспечивать его путем планирования, мониторинга и непрерывной деятельности по повышению уровня Доступности IT- инфраструктуры

Принципы – Доступность – основа удовлетворенности Пользователя и Бизнеса – Повысить доступность можно только поняв, как IT-Сервис поддерживает бизнес – Удовлетворенность Пользователя и Бизнеса может быть достигнута при наличии сбоев и Проблем

Термины Доступность – способность Сервиса или компонента выполнять требуемые функции Надежность – подверженность сбоям Ремонтопригодность – способность к возврату в рабочее состояние

Доступность и Инциденты

Измерение Доступности – %Доступности – %Недоступности – Продолжительность недоступности – Количество сбоев (надежность) – Урон от сбоя

Планирование Доступности Service Desk Управление Инцидентами Ремонтопригодность Требования к Доступности Планирование Надежность Восстановление Обслуживание Доступность

Повышение Доступности – CFIA – FTA – CRAMM

Доступность и стоимость

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

Схема процесса

Сервис Результат взаимодействия поставщика и потребителя Свойства Сервиса:Свойства Сервиса: Неосязаемость Неосязаемость Неотделимость Неотделимость Непостоянство качества Непостоянство качества Несохраняемость Несохраняемость

Управление Непрерывностью ИТ-Сервисов Цель: обеспечить восстановление IT- инфраструктуры (включая Сервисы) в течение требуемого отрезка времени.Цель: обеспечить восстановление IT- инфраструктуры (включая Сервисы) в течение требуемого отрезка времени. Этот процесс – часть процесса управления Непрерывностью бизнеса Этот процесс – часть процесса управления Непрерывностью бизнеса

Управление Мощностью Цель: обеспечить оправданную по затратам мощность IT-инфраструктуры в соответствии с текущими и будущими потребностями бизнеса

Состав SLA Каталог сервисов Каталог сервисов Параметры сервисов Параметры сервисов Спецификация сервисов Спецификация сервисов

Параметры Сервиса – Измеримость – Время/место предоставления – Доступность – Время выполнения запросов

Требования к SLA Уровень Сервиса – совокупность значений параметров СервисаУровень Сервиса – совокупность значений параметров Сервиса Требования к уровню Сервиса - требования к значениям параметров СервисаТребования к уровню Сервиса - требования к значениям параметров Сервиса Согласованный уровень Сервиса – согласованные требования к значениям параметров СервисаСогласованный уровень Сервиса – согласованные требования к значениям параметров Сервиса

SLA, OLA, UC

Мониторинг и отчетность Светофор

PDCA Суть цикла, повышение уровня сервиса, при сохранении качества с течением времени

Совещание – Регулярно – Достигнут ли требуемый уровень Сервиса? – Что помешало? – Как устранить причины помех? – Протокол

Области действия Процесс действует в трех областях: БИЗНЕС СЕРВИС РЕСУРС

Рабочий цикл 57 Настройка Монитори нг АнализИзменение Порог утилизации ресурса Порог из SLA Данные о Мощности Отчеты о нарушени и SLA Отчеты о перегрузке

Прочие операции – Моделирование – «Вписывание» приложений в инфраструктуру – Выпуск плана по Мощности

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

Инициация процесса – Выработка политики – Определение ролей и ответственности – Выделение ресурсов – Организация проекта

Анализ требований и выработка стратегии ВыработкастратегииВыработкастратегии рейтинг рисков Оценка рисков какие бизнес-процессы критические?какие бизнес-процессы критические? что случится, если они остановятся?что случится, если они остановятся? что может им повредить?что может им повредить? насколько реальна угроза?насколько реальна угроза? насколько велик урон?насколько велик урон? меры по снижению рисковмеры по снижению рисков способы восстановленияспособы восстановления Анализ уязвимости бизнеса

Меры по снижению риска Стратегия резервного копированияСтратегия резервного копирования Устранение «точки отказа»Устранение «точки отказа» Аутсорсинг Сервисов нескольким провайдерамАутсорсинг Сервисов нескольким провайдерам Повышение надежности IT-систем и сетиПовышение надежности IT-систем и сети Усиление системы безопасности, включая пожарную безопасностьУсиление системы безопасности, включая пожарную безопасность Внедрение процедур, снижающих вероятность ошибок и сбоев (например, управление Изменениями)Внедрение процедур, снижающих вероятность ошибок и сбоев (например, управление Изменениями)

Способы восстановления НичегонеделаниеНичегонеделание Ручной трудРучной труд Соглашение о взаимопомощиСоглашение о взаимопомощи Медленное восстановление (более 72 ч)Медленное восстановление (более 72 ч) Быстрое восстановление (24-72 ч)Быстрое восстановление (24-72 ч) Немедленное восстановление (до 24 ч)Немедленное восстановление (до 24 ч)

Эксплуатация «PR»«PR» ТренингТренинг Проверка на актуальностьПроверка на актуальность Тестирование компонентовТестирование компонентов Контроль за ИзменениямиКонтроль за Изменениями

Место Service Transition в жизненном цикле

Ключевые принципы Service Transition Понимание всех сервисов, их полезности (utility) и гарантии (warranties). Установление формальной политики и по внедрению всех необходимых изменений. Поддержка изменений в базе знаний, содействие принятию и продолжению использования существующих процессов, систем и т.д. Проактивность в управлении изменения курса. Гарантия соответствия внедренных процессов и процессных требований всему жизненному циклу сервисов.

Ключевые процессы Service Transition Перечень процессов жизненного цикла Service Transition: Change Management Service Asset and Configuration Management Knowledge Management. Процессы фокусированные на Service Transition, но не являющиеся частью Service Transition: Transition Planning and Support Release and Deployment Management Service Validation and Testing Evaluation.

Термины Service Transitions Полезность (Utility) Функциональность, предлагаемая продуктом или сервисом для обеспечения определённых потребностей. Зачастую определяется как «что делает продукт/сервис». Полезность сервиса (Service Utility) Функциональность ИТ-сервиса с точки зрения заказчика. Бизнес-ценность ИТ- сервиса создаётся комбинацией полезности («что сделает сервис») и гарантии («насколько хорошо он это делает»). Гарантия (Warranty) Обещание или гарантия того, что продукт или сервис будет соответствовать согласованным требованиям. Гарантия сервиса (Service Warranty) Уверенность в том, что ИТ-сервис будет соответствовать согласованным требованиям. Может быть в виде формального соглашения, такого как SLA или договор, либо как маркетинговое сообщение или представление торговой марки. Бизнес-ценность ИТ-сервиса создаётся комбинацией полезности («что сделает сервис») и гарантии («насколько хорошо он это делает»).

Создание ценности

Управление Изменениями Цель процесса: обрабатывать все Изменения стандартными методами и процедурами, с тем, чтобы минимизкровать ущерб для бизнеса, вызванный этими Изменениями

Роль Change mgmt в Service Transition Управление бизнесом Управление бизнес- процессами Управление бизнес- активностями Управление IT сервисами Управление поставщиками Управление внешними сервисами Предоставле ние сервисов Портфель сервисов Стратегические изменения Тактические изменения Операционные изменения БизнесСервис провайдер Внешний поставщик

Почему нужно управление Изменениями? Каждое Изменение делается с благими намерениямиКаждое Изменение делается с благими намерениями Каждое Изменение потенциально опасно для предоставляемых СервисовКаждое Изменение потенциально опасно для предоставляемых Сервисов Менеджер по Изменениям – главное действующее лицо данного процессаМенеджер по Изменениям – главное действующее лицо данного процесса

Регистрация и фильтрация RFC (Request For Change) – Запрос на Изменение:RFC (Request For Change) – Запрос на Изменение: Кто, когда?Кто, когда? Что и как нужно изменить?Что и как нужно изменить? Почему это необходимо?Почему это необходимо? Насколько срочно?Насколько срочно? Неразумные предложения отфильтровываютсяНеразумные предложения отфильтровываются

Оценка Изменения – Срочность – Масштаб – Риски при внедрении Изменения (и при отказе от его внедрения) – CAB (Change Advisory Board) – консультативный совет по Изменениям

Координация внедрения – Когда? – Кто? – Как?

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

PIR (Post Implementation Review) Анализ результатов PIR (Post Implementation Review) – Достигнуты ли цели, ради которых делалось Изменение? – Довольны ли пользователи/заказчики результатом? – Возникли ли новые Проблемы?

Связь с другими процессами

Стандартизация Изменений Масштаб изменения:Масштаб изменения: ГлобальноеГлобальное – Оценить – Получить одобрение совета по Изменениям – Произвести Изменение – … БольшоеБольшое СреднееСреднее МелкоеМелкое НезначительноеНезначительное – Произвести изменение – Внести запись в CMDB

Управление Конфигурациями Service Asset and Configuration Management (SACM)Service Asset and Configuration Management (SACM) Цель: SACM поддерживает бизнес, предоставляя актуальную информацию, и актуализируя данные учета единиц инфраструктуры и их отношенийЦель: SACM поддерживает бизнес, предоставляя актуальную информацию, и актуализируя данные учета единиц инфраструктуры и их отношений. Похоже на учет, но это не одно и то жеПохоже на учет, но это не одно и то же

Configuration management System Концепция Configuration Management System (CMS) выстраивается на основании данных заложенных в Configuration Management Database (CMDB) показать сервисы оказываемые бизнесу и все компоненты инфраструктуры, влияющие или принимающие участие в предоставлении этого сервиса. В то время как CMDB требует много времени и ресурсов для заполнения, CMS основывается на технологиях интеграции существующих данных, процессов и исполнителей. CMS не является заменой полноценной CMDB, а только частью отвечающей за учет оборудования и ПО для уже предоставляемых сервисов

Конфигурационная единица (КЕ) Инфраструктура в целом Компьютер ПроцессорДискПамять Монитор

Планирование Задание правил для остальных операцийЗадание правил для остальных операций Задание правил взаимодействия с другими процессамиЗадание правил взаимодействия с другими процессами

Идентификация Каждую КЕ (CI) необходимо обнаружитьКаждую КЕ (CI) необходимо обнаружить Присвоить идентификаторПрисвоить идентификатор ПромарккроватьПромарккровать Внести запись в БД (CMDB- Configuration management data base)Внести запись в БД (CMDB- Configuration management data base)

Контроль Каждое изменение в инфраструктуре должно быть отражено в CMDB

Статус конфигурационной еденицы Заказана Заказана В разработке В разработке На складе На складе Установлена/используется Установлена/используется В ремонте В ремонте Списана Списана В тестировании В тестировании

Отчетность и аудит Текущее состояние инфраструктуры Состояние инфраструктуры на заданную дату История KE (что происходило в течении «жизни») Сверка хранимых и фактических данных Эта операция не вносит изменения в CMDB. Ее результат – отчет

Управление знаниями Цель процесса: Убедиться в том что нужный человек в нужное время обладает нужными знаниями для предоставления сервисов Задачи процесса: Повышение качества предоставляемого сервиса Однозначное и полное понимание ценности сервисов Актуальная и доступная информация.

Управление Релизами и Развертыванием Цель: формирование и установка на положенное место всех аспектов сервисов, обеспечение эффективности использования новых или измененных сервисов.Цель: формирование и установка на положенное место всех аспектов сервисов, обеспечение эффективности использования новых или измененных сервисов. Релиз – совокупность одобренных ИзмененийРелиз – совокупность одобренных Изменений Процесс управления релизами- «руки» процесса управления изменениями

Типы Релизов Полный Релиз: система целикомПолный Релиз: система целиком Частичный Релиз: только части системы, измененные с момента последнего РелизаЧастичный Релиз: только части системы, измененные с момента последнего Релиза Пакетный Релиз: одновременный Релиз нескольких системПакетный Релиз: одновременный Релиз нескольких систем

Схема процесса Управление Релизами База Конфигураций (CMDB) и библиотека ПО (DSL) Установк а Поли тика План иров ание Тести рован ие Разработка или закупка ПО Создание и конфигу- рирование Релиза Прием ка Плани- ровани е устано вки Подготовка и обучение Среда разработки Среда тестирования Рабочая среда

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

Планирование и поддержка Целями процесса Планирования и Поддержки Развертывания являются: Планирование и координация ресурсов чтобы убедиться что требования Service Strategy транслированы в Service Design и эффективно реализованы в Service Operations Идентификация, управление и контроль рисков ошибок и нарушений в момент развертывания процессов.

Тестирование Цель процесса: Убедиться в том все требования к сервису, освещенные в SLA, так же как ценности и гарантии касательные функциональности, доступности, непрерывности, безопасности, простоты и удобства использования, и пути возврата к предыдущим версиям сервисов протестированы и функционируют.

Оценка Цель процесса: Убедиться что предоставленный сервис соотвествует требованиям заказчика, а способы контроля и метрики позволяют оценить его реальную эффективность Ключевой процесс внедрения сервисов (Service Transition)

Место операционной поддержки в жизненном цикле Управление коммуникациями и обязательствами по предоставлению сервисов Управление организационными изменениями на стороне представителя и заказчика Контроль и управление заинтересованными сторонами в предоставлении сервисов Организация процессов Service Transition и ключевых ролей.

Цели Service Operation Цели Service Operation: Обеспечение доставки сервисов согласованного уровня до пользователей и заказчиков. Управление приложениями, технологиями и инфраструктурой которая поддерживает данные сервисы.

Управление событиями и мониторинг Управление событиями наблюдает за событиями, связанными с изменениями в ИТ инфраструктуре и(или) оказываемых ИТ сервисах. Мониторинг – наблюдение за состоянием, данное понятие является более широким, чем управление событиями. Например, средства контроля проверяют состояние устройства на предмет его функционирования в допустимых пределах, даже если это устройство не генерирует никаких событий.

Схема процесса

Ценность внедрения процесса Раннее обнаружение инцидентов Повышение рациональности мониторинга автоматизированных процедур Раннее оповещение о необходимости обновления процедур или ресурсов Основа для автоматизации процедур эксплуатации

Жизненный цикл события 1. Классификация (correlation) 1. Генерация записи об инциденте 2. Регистрация запроса на изменение 3. Эскалация (оповещение) заинтересованных лиц 4. Запуск скрипта, управляющего компонентами инфраструктуры 2. Реакция на событие может включать в себя: 1. Регистрацию произошедшего события 2. Автоматическое исполнения процедур, 3. Запуск процедур других процессов эксплуатации, например процесса управления инцидентами 3. Оценка 4.Закрытие

Возможные конфликты достижения баланса в поддержке Точка зрения IT против точки зрения бизнеса Стабильность против быстроты реакции Качество сервисов против их стоимости Реактивность против проактивности.

Управление событиями Event management Событие – поддающееся обнаружению явление, имеющее значение для управления инфраструктурой ИТ или предоставления ИТ сервисов.

Service Desk, Incident Management Предоставление IT-Сервисов всегда сопряжено со сбоями или, по крайней мере, затруднениями

Что может случиться? Сбой – система не работает так, как должнаСбой – система не работает так, как должна Запрос на обслуживание – сбоя нет. Выполнение запроса безусловное (в рамках Event management)Запрос на обслуживание – сбоя нет. Выполнение запроса безусловное (в рамках Event management) Запрос на изменение – требование изменить систему. Запрос может быть отклоненЗапрос на изменение – требование изменить систему. Запрос может быть отклонен

Инцидент (ITIL) Любое событие, не являющееся частью нормального функционирования Сервиса, которое привело или может привести к прекращению предоставления Сервиса или к снижению его качества.

Service Desk Подразделение – не процесс Цели: Быть единой точкой контакта с пользователями и заказчикамиБыть единой точкой контакта с пользователями и заказчиками Координкровать устранение ИнцидентовКоординкровать устранение Инцидентов

Управление инцидентами Цель: как можно скорее восстановить нормальное, как описано в SLA, предоставление СервисаЦель: как можно скорее восстановить нормальное, как описано в SLA, предоставление Сервиса

Регистрация Когда?Когда? Что случилось?Что случилось? Кто обратился?Кто обратился? Кто зарегистрировал?Кто зарегистрировал?

Классификация Предоставление какого Сервиса нарушено?Предоставление какого Сервиса нарушено? Может ли SD помочь?Может ли SD помочь? Кому направить?Кому направить? Какой приоритет присвоить?Какой приоритет присвоить?

Поиск решения Возможно ли продолжить предоставление Сервиса с понижением его уровня?Возможно ли продолжить предоставление Сервиса с понижением его уровня? Все операции должны быть зафиксированыВсе операции должны быть зафиксированы

Применение решения Ключевой момент процессаКлючевой момент процесса Необходимы ли восстановительные действия?Необходимы ли восстановительные действия? Все операции должны быть зафиксированыВсе операции должны быть зафиксированы

Закрытие По сути - контроль качестваПо сути - контроль качества Согласен ли пользователь с решением?Согласен ли пользователь с решением? Правильно ли оформлены записи?Правильно ли оформлены записи?

Контроль Координирующая функцияКоординирующая функция Задачи:Задачи: – Следить за списком открытых Инцидентов – Эскалкровать Инциденты – Держать пользователей в курсе происходящего

Эскалация Функциональная Иерархическая

Ключевые показатели Количество ИнцидентовКоличество Инцидентов Достигает ли процесс цели?Достигает ли процесс цели? – Количество выполненных/вовремя – Среднее время выполнения Оптимальны ли затраты?Оптимальны ли затраты? – Средняя стоимость выполнения

Жизненный цикл инцидента РегистрацияРегистрация КлассификацияКлассификация Поиск решенияПоиск решения Применение решенияПрименение решения ЗакрытиеЗакрытие

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

Терминология Проблема – неизвестная первопричина одного или более Инцидентов (и сбоев, и запросов на обслуживание)Проблема – неизвестная первопричина одного или более Инцидентов (и сбоев, и запросов на обслуживание) Известная ошибка – состояние, в которое переходит Проблема, когда становится известно, каким недостатком инфраструктуры она вызванаИзвестная ошибка – состояние, в которое переходит Проблема, когда становится известно, каким недостатком инфраструктуры она вызвана

Общая схема процесса Проактивное управление Проблемами Problem control Error control Информация Информация, действия Информация Известная ошибка

Problem control Цель: найти причину (и способ устранения или обхода проблемы)Цель: найти причину (и способ устранения или обхода проблемы) Как:Как: Выявить и зарегистркроватьВыявить и зарегистркровать КлассифицкроватьКлассифицкровать Найти решениеНайти решение

Error control Цель: контролкровать все известные ошибки и при необходимости устранять ихЦель: контролкровать все известные ошибки и при необходимости устранять их Как:Как: – Выявить и зарегистркровать – Оценить – Найти способ устранения – Описать и внести в базу знаний – Закрыть

Взаимосвязь с другими процессами

Проактивное управление Проблемами Цель: устранять Проблемы до возникновения Инцидентов Как:Как: – Собирать и анализкровать информацию – Принимать контрмеры – Предоставлять информацию о Проблемах

Диаграмма Исикавы

КД и ПД Организация должна устранять причины имевшихся и потенциальных несоответствий, чтобы не допустить их (повторного) появления (ГОСТ Р ИСО 9001:2001)

Управление Доступом Цель процесса: предоставление прав для пользователей к сервисам или группам сервисов, во избежание доступа для неавторизованных пользователей.

Управление выполнением запросов Запрос на обслуживание: Запрос пользователя для получения информации, поддержки (консультирования), стандартного изменения, открытия доступа к сервисам IT.

CIA Конфиденциальность (кто имеет доступ к информации)Конфиденциальность (кто имеет доступ к информации) Целостность (не должно быть «неправильной» информации)Целостность (не должно быть «неправильной» информации) Доступность (информация должна быть доступна, тем, кому и когда она нужна)Доступность (информация должна быть доступна, тем, кому и когда она нужна)

Жизненный цикл

Организационные единицы Service Desk Техническое управление Управление Приложениями Операционное управление

Service Desk Регистрация инцидентов и запросов, категоризация и приоритизация. Первая линия поддержки (диагностика и выявление причин) Управление жизненным циклом инцидентов и сервисных запросов, эскалация и реагирование. Информирование пользователей о статусах запросов и обращений по инцидентам.

Техническое управление Technical Management включает всех исполнителей, которые проводят технические экспертизы и управляют инфраструктурой. по service design, service transition или управлению непрерывноНаполнение aбазы знаний, и экспертная оценка требований Достижение построение архитектуры в соответствии с выработанным стандартом Улучшения в дизайне и построении новых сервисов и сценариев оперативной поддержки Проведение проектов стью улучшения качества сервисов Участие в управлении Уровнем Сервиса, помощь в достижении выработанных стандартов и инструментов, совершение действий по обработке запросов на изменения Помощь в управлении поставщиками

Управление приложениями Application Management: включает всех исполнителей, которые производят технические экспертизы и управляют приложениями. Роль похожа на to Technical Management, но более сфокусирована на ПО И приложениях, работающих в инфраструктуре.

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

Постоянное улучшение сервисов Continual Service Improvement (CSI) занят разработкой шагов по повышению качества предоставляемых сервисов в рамках жизненного цикла процессов ITSM Виденье Бизнес виденье, цели Аудит Измеримые цели Улучшения сервисов и процессов Метрики и оценка Где мы сейчас? Где мы хотим быть Как мы туда дойдем Уже дошли? Как будем продолжать двигаться?

Путь к улучшению Определение Виденье Стратегия Тактика Операционное обслуживание 1. Что должны измерять 2. Что можем измерять? 3. Сбор данных, Кто, когда и как 4. Обработка данных 5. Анализ данных Отношения? Тенденции? Соответствия плану? Цель достигнута? Корректирующие? 6. Представление с использованием информации, результатов аудита, планы действий, etc. 7. Произведение корректирующих действий Цели

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

Системы автоматизации Систем автоматизации процессов существует масса. Главное не система автоматизации а процесс. Система автоматизации не панацея. Хорошая система автоматизации: Известность на рынкеИзвестность на рынке Схема внедрения логична и понятнаСхема внедрения логична и понятна Гарантированная поддержкаГарантированная поддержка Обучение персоналаОбучение персонала Схема обновленияСхема обновления

Ключевые факторы успеха Поддержка руководства Поддержка руководства Поддержка сотрудников ИТ Поддержка сотрудников ИТ Профессиональная комманда внедрения Профессиональная комманда внедрения Проектное управление Проектное управление

План проекта внедрения Обучение Обучение Формирование команды Формирование команды Аудит Аудит Формализация процессов Формализация процессов Внедрение Внедрение

Дельта-Банк Дельта-Банк Финансы и кредит Финансы и кредит Райффайзен банк Аваль Райффайзен банк Аваль Приоком (телеком оператор) Приоком (телеком оператор)

Вопросы ?