Управление инцидентами

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

Поделиться

Share on facebook
Share on linkedin
Share on twitter
Share on email

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

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

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

 

Фактор успеха практики: сложный функциональный компонент практики, необходимый для выполнения этой цели.

Фактор успеха практики (PSF) – это больше, чем задача или действие; он включает в себя компоненты из всех четырех измерений управления услугами. Характер деятельности и ресурсы фактора успеха практики в рамках практики могут различаться, но вместе они обеспечивают эффективность практики.

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

  • ранее обнаружение инцидентов
  • разрешение инцидентов быстро и эффективно
  • постоянно совершенствовать подходы к управлению инцидентами.

Эффективность и производительность практик ITIL следует оценивать в контексте потоков создания ценности, которым способствует каждая практика. Как и в случае производительности любого инструмента, производительность практики может оцениваться только в контексте его применения. Однако инструменты могут сильно различаться по дизайну и качеству, и эти различия определяют потенциал или способность инструмента быть эффективным при использовании в соответствии с его назначением. Дополнительное руководство по метрикам, ключевым показателям эффективности (KPI) и другим методам, которые могут помочь в этом, можно найти в практике по измерению и отчетности.

 

Организации и Люди

Здесь мы рассмотрим, как практика по управлению услугами учитывает все аспекты Организации и Людей, одного из 4 измерений управления услугами.

ITIL 4 представил профили компетенций: (L) Лидер, (A)Администратор, (C) Координатор / Коммуникатор, (M) Эксперт по методам и техникам и (T) Технический эксперт. Эти профили компетенций отличаются от матрицы RACI. Профили компетенций основаны на компетенциях и навыках, необходимых для выполнения функций специалистов.

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

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

 

Организационная структура

Многоуровневые и горизонтальные командные структуры

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

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

Динамика команды

Практика управления инцидентами является основой динамики команды, потому что они влияют на функционирование операции поддержки. Следующие ошибки регулярно повторяются:

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

Это приводит к тому, что практика по управлению инцидентами не синхронизируется, решения происходят медленно или вообще не происходят, снижение морального духа, отсутствие мотивации и нездоровая степень конкурентоспособности на рабочем месте. Кроме того, доверие между членами команды рушится. Такие подходы, как DevOps и swarming, показывают некоторые характеристики, необходимые для поощрения позитивной культуры, хотя нет необходимости следовать этим подходам для достижения правильной динамики команды. Следующие три основные области должны быть рассмотрены.

Коллективная ответственность

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

Культура без вины

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

Непрерывное обучение

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

 

Потоки создания ценности и процессы

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

 

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

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

 

Процесс обработки и разрешения инцидентов состоит из следующих активностей:

  • Обнаружение инцидентов
  •  Регистрация инцидентов
  • Классификация инцидентов
  • Диагностика инцидента
  • Разрешение инцидента
  • Закрытие инцидента

Периодический процесс анализа инцидентов состоит из следующих активностей:

  • Обзор инцидентов и анализ записей инцидентов
  • Инициирование улучшения модели инцидента
  • Коммуникации об обновлении модели инцидента

 

 

Информация и Технология

Детали инцидентов являются наиболее важной информацией. Обычно они включают в себя:

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

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

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

 

 

Партнёры и поставщики

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

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

 

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

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

Подпишитесь на рассылку

Мы будем направлять Вам различные новости

Вас также может заинтересовать...

External-providers-SLA
SLA

Управление уровнем услуг внешних поставщиков

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

4-совета-для-менеджеров-по-закупкам
SaaS

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

Многие поставщики SaaS по-прежнему используют модели ценообразования, которые серьезно ограничивают гибкость их клиентов. Ниже приведены несколько простых советов, которые помогут заключить более выгодные условия с поставщиками программного обеспечения SaaS.
1. Избегайте привязки к одному поставщику решений
2. Платите после запуска (Go-Live).
3. Масштабируйте вверх и вниз
4. Исключите проекты по обновлению

Мы здесь, чтобы Вам помочь

Оставьте нам заявку и наши консультанты свяжуться с Вами