Портал №1 по управлению цифровыми
и информационными технологиями

ITSM 101: Управление инцидентами в сравнении с управлением проблемами

Давайте поговорим об управлении инцидентами и проблемами. Дело вот в чем. ITIL существует с конца 1980-х годов. Сейчас мы находимся на четвертой версии (ITIL 4), но, несмотря на огромное количество книг, курсов и сообщений в блогах об ITIL, до сих пор существует путаница в вопросе о том, где заканчивается управление инцидентами и начинается управление проблемами. Плюс разница между этими двумя понятиями. Если бы это был просто терминологический вопрос, я бы не стал так беспокоиться об этом, но реальность такова – путаница в управлении инцидентами и проблемами вредит всем нам.

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

Мы все слышали о Бэтмене против Супермена (комиксы и фильм), и чтобы раз и навсегда покончить с путаницей в управлении инцидентами и проблемами, я хочу поговорить об этом: Бэтмен против Коломбо.

Бэтмен против Коломбо: объяснение

Давайте вернемся к основам управления инцидентами и проблемами. Управление инцидентами — это процесс, который восстанавливает услугу как можно быстрее и с минимальными негативными последствиями. Другими словами, персонал по управлению инцидентами — это супергерои в мире управления ИТ-услугами (ITSM), прилетающие, как Бэтмен, чтобы спасти положение, т.е. восстановить работу и бизнес.

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

Надеюсь, эта аналогия с управлением инцидентами и проблемами поможет 🙂.

Лучшие советы по управлению инцидентами и проблемами в реальном мире

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

  1. Собирайте правильную информацию для управления проблемами

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

  • Имя
  • Контактная информация
  • Идентификатор сотрудника
  • Обозначение актива
  • Статус VIP/критического пользователя
  • Местонахождение
  • Статус
  • Тип
  • Приоритет
  • Категория
  • Название
  • Описание
  • Затронутые услуги
  • Назначенные команды
  • Детали решения
  • Детали исправления
  • Связанная запись о проблеме

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

  • Описание проблемы
  • Затронутые услуги и влияние на бизнес
  • Время простоя
  • Приоритет
  • Действия по устранению проблемы на сегодняшний день
  • Информация о команде поддержки
  • Анализ первопричины
  • Протокол совещания
  • Следующие шаги
  • Связанные инциденты
  • Связанные изменения

Поэтому не смешивайте эти два понятия, так как это влияет на ваши возможности управления инцидентами и проблемами.

  1. Выделите отдельные роли для управления инцидентами и проблемами

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

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

  1. Определите точки передачи между управлением инцидентами и проблемами

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

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

  1. Не забывайте о постоянном совершенствовании управления инцидентами и проблемами

Будьте проактивны! Обеспечьте работу отдела управления инцидентами и проблемами как единой команды для просмотра производительности услуг в течение месяца. Заведите процесс автоматического создания новой проактивной записи о проблеме, если целевые показатели доступности находятся под угрозой, чтобы можно было принять меры для предотвращения дальнейших проблем. Не сидите и не ждите, пока не будет нарушено SLA. И продолжайте двигаться вперед – небольшие постепенные улучшения могут действительно накапливаться со временем; это называется эффектом предельного выигрыша.

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

  1. Не забывайте о значительных инцидентах во всех этих разговорах об управлении инцидентами и проблемами!

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

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

  1. Коммуникация — это все

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

В заключение: управление инцидентами и проблемами

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

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

Оригинал статьи можно найти здесь.

Комментариев: 4

  • Для погружения в тему может быть и ОК.
    Но, как мне кажется, стоит уточнить пару моментов.

    При всём уважении к Vawns Murphy, автору статьи, разделять персонал на тех, кто занимается решением инцидентов и тех, кто занимается решением проблем, неверно. В общем случае. Такое разделение до какой-то степени возможно. Но не является обязательным. Т.е. одни и те же люди могут быть задействованы в обеих практиках. Разные менеджеры – стандартная рекомендация. Хотя. Как мы знаем, и с этим в реальной жизни бывает по-разному 😊
    Таким образом, попытка объяснить разницу между практиками, через разделение людей/подразделений приведёт к непониманию (обоснованно!) со стороны тех, у кого в организации это одни и те же (ну, ОК, пересекающиеся) группы сотрудников.
    Разница между INC и PRB не в том, что это разные люди!

    Кроме того, пользуясь аналогией автора, предполагать, что Бэтмен действует безмозгло, а Коломбо потом проанализирует и разберётся – тоже довольно серьёзное упрощение. Анализ, включая поиск корневых причин не является вотчиной исключительно Problem management. Это слишком сильное упрощение.

    Для заявленного в заголовке заметки уровня (ITSM101) – OK. Но, по-моему, пара вышеуказанных упрощений может сослужить плохую службу на практике.

    PS параграф 5 к разговору отношения не имеет, если под целью статьи понимать, то, что написано во вводной части «нам нужно сесть и объяснить разницу между инцидентами и проблемами».

    • Разные менеджеры – стандартная рекомендация.

      А, кстати, почему их нужно разделять?

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

    Я бы сказал более жёстко.
    Разделять персонал на решателей инцидентов и устранителей проблем вредно. Потому что 1) в итоге работа и тех, и других направлена на одно и тоже – повышение uptime, 2) при выделении отдельно аналитиков сложно мотивировать на свершения, а если они же и бегают по инцидентам – то мотивация упрощается.

  • Андрей Виноградов

    Чтобы не дискутировать – предлагаю разделить роли INC и PRB, а не людей. Замените “Менеджер” на “Роль” (ну или функцию, если прям совсем академически). А дальше зависит от моделей и масштабов управления 🙂


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM