Давайте поговорим об управлении инцидентами и проблемами. Дело вот в чем. ITIL существует с конца 1980-х годов. Сейчас мы находимся на четвертой версии (ITIL 4), но, несмотря на огромное количество книг, курсов и сообщений в блогах об ITIL, до сих пор существует путаница в вопросе о том, где заканчивается управление инцидентами и начинается управление проблемами. Плюс разница между этими двумя понятиями. Если бы это был просто терминологический вопрос, я бы не стал так беспокоиться об этом, но реальность такова – путаница в управлении инцидентами и проблемами вредит всем нам.
Если существует путаница в практике/процессах управления инцидентами и проблемами, то нам нужно сесть и объяснить разницу между инцидентами и проблемами. В противном случае одни и те же инциденты будут повторяться, мы по-прежнему будем полагаться на отдельных героев, чтобы исправить ситуацию, не будет проведен анализ первопричины, поэтому ничего не будет исправлено навсегда, и возможности для постоянного улучшения будут упущены.
Мы все слышали о Бэтмене против Супермена (комиксы и фильм), и чтобы раз и навсегда покончить с путаницей в управлении инцидентами и проблемами, я хочу поговорить об этом: Бэтмен против Коломбо.
Бэтмен против Коломбо: объяснение
Давайте вернемся к основам управления инцидентами и проблемами. Управление инцидентами — это процесс, который восстанавливает услугу как можно быстрее и с минимальными негативными последствиями. Другими словами, персонал по управлению инцидентами — это супергерои в мире управления ИТ-услугами (ITSM), прилетающие, как Бэтмен, чтобы спасти положение, т.е. восстановить работу и бизнес.
Однако основными целями управления проблемами являются устранение повторяющихся инцидентов (проблем) и минимизация последствий инцидентов, которые невозможно предотвратить. Другими словами, специалисты по управлению проблемами появляются после восстановления нормальной работы услуги и, подобно Коломбо, выступают в роли детективов, выясняя, что произошло, что вызвало неполадки, как они были устранены и как предотвратить их повторение. И, надеюсь, никаких трупов обнаружено не будет.
Надеюсь, эта аналогия с управлением инцидентами и проблемами поможет 🙂.
Лучшие советы по управлению инцидентами и проблемами в реальном мире
Итак, теперь, когда я объяснил разницу между управлением инцидентами и проблемами, вот мои главные советы по их правильному использованию.
-
Собирайте правильную информацию для управления проблемами
Записи об инцидентах связаны с восстановлением услуги или, как его обычно называют, устранением неполадок. Для записи инцидента обычно требуется следующая информация (надеюсь, что большая часть уже хранится в вашей службе поддержки или инструменте ITSM):
- Имя
- Контактная информация
- Идентификатор сотрудника
- Обозначение актива
- Статус VIP/критического пользователя
- Местонахождение
- Статус
- Тип
- Приоритет
- Категория
- Название
- Описание
- Затронутые услуги
- Назначенные команды
- Детали решения
- Детали исправления
- Связанная запись о проблеме
Записи о проблемах и управление проблемами, с другой стороны, связаны с анализом первопричины. Записи о проблемах обычно содержат следующую информацию:
- Описание проблемы
- Затронутые услуги и влияние на бизнес
- Время простоя
- Приоритет
- Действия по устранению проблемы на сегодняшний день
- Информация о команде поддержки
- Анализ первопричины
- Протокол совещания
- Следующие шаги
- Связанные инциденты
- Связанные изменения
Поэтому не смешивайте эти два понятия, так как это влияет на ваши возможности управления инцидентами и проблемами.
-
Выделите отдельные роли для управления инцидентами и проблемами
Организуйте управление инцидентами и проблемами таким образом, чтобы не было дублирования или напрасных усилий. Короче говоря, менеджер по инцидентам заботится о скорости, в то время как менеджер по проблемам занимается расследованием и диагностикой для повышения качества сквозной услуги.
Основные приоритеты менеджера по инцидентам включают координацию инцидента, управление коммуникациями с командами технической поддержки и клиентами, а также обеспечение скорейшего устранения неисправности. В то время как менеджер по проблемам и управление проблемами будут сосредоточены на изучении первопричины, отслеживании тенденций (появлялась ли эта проблема раньше?), поиске исправлений (временных обходных решений и постоянного решения), а также обеспечении документирования и применения всех извлеченных уроков по управлению инцидентами и проблемами.
-
Определите точки передачи между управлением инцидентами и проблемами
Очень важно следить за обычными операциями, поскольку, казалось бы, незначительные инциденты могут выйти из-под контроля и оказать негативное влияние на уровень доступности и удовлетворенность клиентов. Простые вещи могут иметь большое значение. Например, разместив рядом со службой поддержки доску со списком десяти наиболее распространенных проблем, аналитики службы поддержки смогут легко связать инциденты с проблемами, чтобы впоследствии выявить тенденции. Или, если служба поддержки проводит командное совещание, попросите менеджера по проблемам (или аналогичного специалиста) принять в нем участие, чтобы проинформировать их о любых новых проблемах, обновлениях и обходных решениях для решения существующих проблем.
Наконец, не забудьте замкнуть цикл управления проблемами и сообщить службе технической поддержки, когда запись о проблеме была исправлена и закрыта. Нет ничего хуже для службы технической поддержки, чем обзванивать список клиентов по поводу проблемы, которая была решена несколько месяцев назад (что случается, когда управление инцидентами и проблемами не работают вместе).
-
Не забывайте о постоянном совершенствовании управления инцидентами и проблемами
Будьте проактивны! Обеспечьте работу отдела управления инцидентами и проблемами как единой команды для просмотра производительности услуг в течение месяца. Заведите процесс автоматического создания новой проактивной записи о проблеме, если целевые показатели доступности находятся под угрозой, чтобы можно было принять меры для предотвращения дальнейших проблем. Не сидите и не ждите, пока не будет нарушено SLA. И продолжайте двигаться вперед – небольшие постепенные улучшения могут действительно накапливаться со временем; это называется эффектом предельного выигрыша.
Включите непрерывное совершенствование в процессы управления инцидентами и проблемами для изучения “собственных целей” при рассмотрении значительных инцидентов и извлеченных уроков при решении проблем и известных ошибок. Добавьте их в реестр совершенствований, чтобы эти идеи по улучшению документировались, отслеживались и – самое главное – принимались во внимание. Особенно это касается управления проблемами.
-
Не забывайте о значительных инцидентах во всех этих разговорах об управлении инцидентами и проблемами!
Очень многие паникуют и выбрасывают все свои наработки в окно, когда сталкиваются с особенно сложным значительным инцидентом, как для персонала по управлению инцидентами, так и для персонала по управлению проблемами, поэтому давайте заранее разработаем план действий. Ваша команда управления службой поддержки и менеджеры по инцидентам лучше всего подходят для работы со значительными инцидентами. Они имеют дело с реактивными и болезненными проблемами изо дня в день. Они лучше всего справляются с первичным пожаротушением и устранением неполадок. Занятые, быстро развивающиеся, реактивные действия — это их любимое место, поэтому позвольте им делать то, что они умеют лучше всего – разобраться с проблемой и устранить ее как можно быстрее и с минимальными негативными последствиями для бизнеса.
Но управление инцидентами не должно получить всю славу! Когда обслуживание восстановлено и все успокоились, реальную пользу может принести эффективный анализ первопричин. В этом вам поможет команда по управлению проблемами. Иногда большего можно добиться в спокойном, безопасном, не подверженном осуждению пространстве, где каждый рассматривает, что пошло не так, как надо, как это было исправлено, были ли извлечены уроки, и можно ли что-то сделать для предотвращения повторения, а не в течение нескольких недель реактивного пожаротушения. Поэтому при работе со значительными инцидентами выделяйте место для практики управления как инцидентами, так и проблемами.
-
Коммуникация — это все
Управление инцидентами и проблемами — это две стороны одной медали. Одна из них сосредоточена на скорости и эффективности, другая более ориентирована на детали и заботится о долгосрочном качестве услуги. Обе стороны необходимы для управления и поддержания отличного уровня услуг, поэтому обеспечьте хорошее взаимодействие обеих команд. Пусть члены команды по управлению проблемами посещают собрания команды службы поддержки, чтобы сообщать о проблемах, известных ошибках и обходных решениях. И наоборот – представители службы поддержки должны присутствовать на совещаниях по расследованию проблем, чтобы можно было полностью понять их влияние на бизнес и зафиксировать любые новые технические детали или симптомы неисправности.
В заключение: управление инцидентами и проблемами
При правильном подходе управление инцидентами позволяет быстро, эффективно и безопасно устранять неполадки, а управление проблемами дополняет усилия по устранению неполадок, обеспечивая поддержку в последующий период, подтверждая первопричину и предотвращая возникновение неполадок в будущем.
Ценность процессов управления инцидентами и проблемами возрастает в геометрической прогрессии, когда они работают вместе, а не изолированно. Когда управление инцидентами сочетается с управлением проблемами, это выводит предложение ИТ-поддержки на новый уровень – вместо того, чтобы просто сосредоточиться на устранении неполадок, вы переходите к модели, которая рассматривает основную причину (причины) и способы улучшения ситуации для клиента.
Оригинал статьи можно найти здесь.
Для погружения в тему может быть и ОК.
Но, как мне кажется, стоит уточнить пару моментов.
При всём уважении к Vawns Murphy, автору статьи, разделять персонал на тех, кто занимается решением инцидентов и тех, кто занимается решением проблем, неверно. В общем случае. Такое разделение до какой-то степени возможно. Но не является обязательным. Т.е. одни и те же люди могут быть задействованы в обеих практиках. Разные менеджеры – стандартная рекомендация. Хотя. Как мы знаем, и с этим в реальной жизни бывает по-разному 😊
Таким образом, попытка объяснить разницу между практиками, через разделение людей/подразделений приведёт к непониманию (обоснованно!) со стороны тех, у кого в организации это одни и те же (ну, ОК, пересекающиеся) группы сотрудников.
Разница между INC и PRB не в том, что это разные люди!
Кроме того, пользуясь аналогией автора, предполагать, что Бэтмен действует безмозгло, а Коломбо потом проанализирует и разберётся – тоже довольно серьёзное упрощение. Анализ, включая поиск корневых причин не является вотчиной исключительно Problem management. Это слишком сильное упрощение.
Для заявленного в заголовке заметки уровня (ITSM101) – OK. Но, по-моему, пара вышеуказанных упрощений может сослужить плохую службу на практике.
PS параграф 5 к разговору отношения не имеет, если под целью статьи понимать, то, что написано во вводной части «нам нужно сесть и объяснить разницу между инцидентами и проблемами».