Смартсорсинг.ру

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

Статьи в блогах Вопросы и ответы Темы в лентах ITSM 365 Пользователи Компании Лента заказов Курс по ITSM

6 «столпов» управления инцидентами

6 «столпов» управления инцидентами

В библиотеке ITIL много внимания уделяется повествованию о том, что можно сделать для того, чтобы эффективно и с пользой управлять ИТ-сервисами. Но, к сожалению, ключевые аспекты внедрения процессов не освещены в достаточной степени. По этой причине в ходе внедрения ITIL возникают вопросы: «С чего начать?», «Как много мы уже сделали?» и «Можно ли перераспределить усилия на другие процессы управления ИТ-сервисами?». В своей заметке на сайте ITSMWatch  Hank Marquis предлагает 6 основных аспектов процесса управления инцидентами.

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

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

  • Создайте базу данных записей обо всех инцидентах. Необходимо фиксировать все возникающие инциденты, независимо от способа их поступления (электронная почта, телефонный звонок, факс и т.д.). Убедитесь, что вся информация о ходе решения инцидента так же фиксируется в базе данных.
  • Создайте базу данных, где будет содержаться дополнительная информация для разрешения инцидента. Чем больше информации, тем лучше. Такой базой данных в терминологии ITIL является CMDB.
  • Разработайте и донесите до всех участников четкие инструкции и правила обработки инцидентов (регистрация, классификация, эскалация и т.д.).
  • Определите, в привязке к SLA, процедуры, которые позволят вам управлять воздействием (impact) инцидента на бизнес.
  • Создайте модель  «главного инцидента» – набор правил четко описывающих очень серьёзный инцидент. Под главным инцидентом понимается такой, который затрагивает критичный бизнес-сервис и/или большое количество заказчиков и пользователей. В любом случае, главный инцидент требует немедленной эскалации, уведомления заказчиков и другой специальной обработки.  Вся суть заключается в том, что такой инцидент требует максимальной реакции со стороны ИТ-организации.
  • Информируйте тех, кто сообщил вам об инциденте, о статусе работ. Вам необходимо представлять, кому и как часто необходимо направлять информацию. Например, Вы можете уведомить об инциденте заказчиков и пользователей. Вы должны также проинформировать их о невозможности  вернуть уровень предоставляемого сервиса к согласованным параметрам в согласованное время.

Если у вас не реализован хотя бы один из этих 6 пунктов, то, в соответствии со стандартом ISO/IEC 20000-1 (Service Management), сфокусировавшись на нем, вы сможете улучшить качество сервиса. Если же все пункты у вас реализованы, то, скорее всего, вам уже не нужно тратить много времени на внедрение процесса управления инцидентами – сосредоточьтесь на других областях ITIL, таких как Управление проблемами (Problem Management) или Управление изменениями (Change Management).

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

Хочется отметить, что вовсе не обязательно держать в голове ITIL, осуществляя эти 6 шагов. Вы можете найти собственное решение или использовать любой другой ITSM-фреймворк. Однако, ITIL – всемирный стандарт де-факто, содержащий наиболее зрелые практики управления ИТ-сервисами. И, что важно, описанные выше 6 аспектов – это минимум из разряда «must have», достигнув которого можно ожидать тех преимуществ, о которых говорит ITIL.

Комментарии (4)

  • Аватар

    Рубинштейн Кирилл [krubinshteyn], 15 июля 2010, 11:51

    0
    С первыми пятью пунтками соглашусь -- действительно из разряда "must have". Но вот по поводу оповещений не моглашусь. Безусловно, оповещать нужно, но это все больше в сторону "лояльности". Основная же задача IM -- решать инциденты быстро с минимальным вредом для бизнеса. Можно сказать, что оповещения о ходе решения инцидента помогают бизнесу сориентироваться в сроках и планировать текущую работу. Но это как-то притянуто за уши и маловато для того, чтобы пункт о исчерпывающих оповещениях считался "must have" для ощущения преимуществ IM.
    • Аватар

      Полюх Андрей Владимирович [AN2], 15 февраля 2011, 16:00

      1
      Уведомление о стадии работ по инциденту, может быть очень полезным, в частности для примера: Инцидент - отсутствие качественного интернет доступа (по вине сотового оператора) торговых представителей с мобильной торговлей на КПК. Решить данную проблему за кротчайший срок не возможно по причине тормозов в службе оператора, уведомление может быть использовано как команда для перехода работы ТП в альтернативный режим сброса заказов (таким образом, как раз с точки бизнес эффективности, важней не как можно быстрей решать проблему доступа, а быстрей доставить заказ альтернативным путем). Конечно для всех случаев это выглядит избыточно. Можно уведомления посылать только для определенных инцидентов, но здесь есть подводный камень, кто будет определять те самые определенные инциденты и не усложнит ли при этом весь процесс, что в итоге может привести к потенциальным сбоям.
  • Аватар

    Солопов Павел [PaSol], 15 июля 2010, 14:37

    0
    Лень лезть в первоисточники, чтобы уточнить, какие же преимущества IM приводит ITIL. Но если смотреть с точки зрения "Основная же задача IM -- решать инциденты быстро с минимальным вредом для бизнеса", то "Необходимо фиксировать все возникающие инциденты, независимо от способа их поступления. Убедитесь, что вся информация о ходе решения инцидента так же фиксируется в базе данных." Для быстрого решения инцидента надо не тратить время и силы на регистрацию и описание, а заниматься его устранением. Причём с регистрацией инцидентов, на мой взгляд, какая ситуация получается: для того, чтобы зарегистрировать инцидент, надо понять что это именно инцидент, поскольку не всякое сообщение по e-mail или телефонный звонок априори связан с инцидентом. По хорошему надо говорить во-первых, о регистрации всех обращений и сообщений, а потом уже об организации выделения из этого потока сообщений, указывающих на инцидент. Но это как-то, по-моему, немного за рамками существующих версий ITIL.
    • Аватар

      Andrey Moisseyev [masya], 17 марта 2011, 11:20

      0
      Есть еще понятие - отложеная регистрация, когда инцидент устраняется а потом заносится в базу

Также рекомендуем