Управление инцидентами в IT может быть не только про IT. Инцидент менеджмент это


Процесс управления инцидентами (Incident Management)

Инцидент (incident или INC) – любое событие (сбои, запросы на консультации и т.п,), не являющееся частью нормальной работы услуги, ведущее/способное привести к остановке услуги или снижению уровня её качества.

Цель процесса управления инцидентами — скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса.

Для успешного управления инцидентами необходимо создание диспетчерской службы (Service desk), которая должна являться единой точкой контакта с пользователями и координирует устранение инцидентов. Service Desk — подразделение (в терминологии ITIL «функция»), обеспечивающее единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов.

Эскалация – механизм, служащий своевременному разрешению INC с помощью привлечения дополнительных знаний (функциональная эскалация) или полномочий (иерархическая эскалация). Цель — решить INC в срок указанный в SLA.

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

Различают функциональную и иерархическую эскалацию:

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

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

Маршрутизация инцидента, или функциональная эскалация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки.

Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это раз­граничение иногда может запутывать, но его главное достоинство заключается в установлении разли­чия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением.

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

Hank Marquis предлагает 6 основных аспектов процесса управления инцидентами:

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

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

В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание.

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

Примеры Запросов на Обслуживание:

  • вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;
  • запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;
  • запрос о замене пароля;
  • запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;
  • получение информации из базы данных.

Для того чтобы можно было отличить “настоящие инциденты” от “инцидентов-Запросов на Обслу­живание“, рекомендуется присваивать Запросам на Обслуживание специальную категорию.

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обос­нованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользо­вателя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уров­нях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определя­ющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более ли­нии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

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

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

 

www.smlogic.ru

Управление инцидентами и проблемами — понятия и принципы

Введение

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

Язык инцидентов и проблем

ITIL Service Support — признанная в мире модель. Она основана на передовом опыте и используется как руководство ИТ-организациями при разработке подходов к управлению обслуживанием. Эта модель перспективна. Также она определяет дополнительные элементы, необходимые для успешного функционирования ИТ-организации как сервисного бизнеса. Она предоставляет технический словарь для обсуждения службы поддержки, определяет понятия и раскрывает отличия между различными видами деятельности. Например, деятельность, необходимая для реагирования на прерывания сервиса, его восстановления, отлична от деятельности по поиску и устранению причин, из-за которых прерывается обслуживание.

Инциденты

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

Примерами инцидентов являются:

  1. Пользователь не может получить e-mail
  2. Средство мониторинга сети указывает, что канал связи вскоре переполнится
  3. Пользователь ощущает замедление работы приложения

Проблемы

Проблема — есть неизвестная причина одного или более инцидентов.Одна проблема может породить несколько инцидентов.

Ошибки

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

Примеры ошибок включают:

  1. Неправильная сетевая конфигурация компьютера
  2. Средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора

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

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

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

Она включает в себя:

  1. Выявление и регистрация инцидентов
  2. Классификация и начальная поддержка
  3. Исследование и диагностика
  4. Решение и восстановление
  5. Закрытие
  6. Владение, мониторинг, отслеживание и связь

Управление проблемами

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

Управление проблемами включает:

  1. Контроль проблем
  2. Контроль ошибок
  3. Предотвращение проблем
  4. Анализ основных проблем

Контроль проблем

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

  1. Идентификация и регистрация проблем
  2. Классификация проблем и определение приоритетов их решений
  3. Исследование и диагностика причин

Контроль ошибок

Контроль ошибок обеспечивает исправление проблем за счет следующих действий:

  1. Идентификация и регистрация известных ошибок
  2. Оценка способов устранения и расстановка приоритетов
  3. Регистрация по временному обходу ошибки в средствах службы поддержки
  4. Закрытие известных ошибок путем осуществления исправлений
  5. Мониторинг известных ошибок для определения необходимости в изменении приоритетов

Анализ проблем

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

Организационные роли и распределение ответственности

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

Первый уровень поддержки

Организация (подразделение), представляющая первый уровень поддержки обычно относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Help Desk, Service Desk.

Роли. Владелец процесса

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

Первая линия поддержки

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

Обязанности
  • Точная регистрация инцидентов. Первый уровень поддержки гарантирует, что информация об инциденте вносится в журнал системы. Для этого должно быть:

    • Гарантировано, что карточка инцидента содержит точное и достаточно детальное описание проблемы
    • Гарантирован правильный выбор важности/приоритета инцидента
    • Определена природа проблемы, контакты пользователя, влияние на бизнес и ожидаемое время решения
  • Владение каждым инцидентом. Как адвокат конечного пользователя первый уровень поддержки обеспечивает успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:

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

  • Непрерывное улучшение процесса управления инцидентами. Как владелец данного процесса первый уровень поддержки гарантирует улучшение при необходимости процесса посредством:

    • Оценки эффективности данного процесса и таких механизмов поддержки, как отчеты, виды связи и форматы сообщений, процедуры эскалации
    • Разработки специфических для подразделений отчетов и процедур
    • Поддержки и совершенствования взаимодействия и списков эскалации
    • Участие в процессе анализа проблем
Способности и навыки
  • Навыки межличностного общения первостепенны. Персонал первого уровня поддержки вовлечен главным образом в расстановку приоритетов и управление проблемами. На этом уровне поддержки проводятся лишь незначительные технические изыскания. Способность применять «консервированные» решения. Персонал первого уровня должен уметь распознавать симптомы, применять поисковые инструменты для обнаружения ранее разработанных решений и помогать конечным пользователям в применении таких решений.

Второй уровень поддержки

Этот уровень также обычно относится к оперативным службам.

Роли
  • Исследование инцидентов. Второй уровень поддержки изучает, диагностирует и решает большинство инцидентов, которые не были решены на первом уровне. Эти инциденты имеют тенденцию указывать на новые проблемы.
  • Владелец процесса управления проблемами. Второй уровень поддержки обеспечивает, что имеет место хорошо определенный и эффективный процесс управления проблемами.
  • Упреждающее управление инфраструктурой. Второй уровень поддержки использует инструменты и процессы, чтобы гарантировать, что проблемы выявляются и решаются до возникновения инцидентов.
Обязанности
  • Решение инцидентов, переданных с первого уровня. Если для первого уровня поддержки ожидается, что он решает 80% инцидентов, то от второго уровня поддержки ожидается, что он решает 75% инцидентов, переданных ему первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.
  • Определение причин проблем. Второй уровень поддержки определяет причины проблем и предлагает меры по их обходу или устранению. Они привлекают и управляют другими ресурсами по мере необходимости для определения причин. Решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации.
  • Обеспечение реализации исправлений и устранений проблем. Второй уровень поддержки обеспечивает инициирование проектов в организациях разработчиках для реализации планов устранения известных ошибок. Они обеспечивают документирование найденных решений, сообщают о них персоналу первого уровня и реализуют их в инструментах.
  • Постоянный мониторинг инфраструктуры. Второй уровень поддержки пытается идентифицировать проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций.
  • Заблаговременный анализ тенденций инцидентов. Уже случившиеся инциденты исследуются для того, чтобы определить не свидетельствуют ли они о наличии проблем, которые следует исправить, чтобы они не вызвали новые инциденты. Исследуются те инциденты, которые закрыты и не сопоставлены известным проблемам, на предмет наличия потенциальных проблем.
  • Постоянное совершенствование процесса управления проблемами. Как владелец процесса управления проблемами второй уровень поддержки гарантирует, что процесс и имеющиеся возможности адекватны и улучшает их при необходимости. Они проводят сессии анализа проблем, чтобы выявить полученные уроки и гарантировать, что средства контроля над процессом, такие как совещания и отчеты, адекватны.
Способности и навыки
  • Технически компетентны с разумными навыками общения. Персонал второго уровня поддержки должен иметь спектр технических навыков по всем поддерживаемым технологиям, включая сети, сервера и приложения. Общим дефицитом в организациях второго уровня являются знания в области операционных систем и приложений. Не должно быть значительного разрыва между организациями второго и третьего уровней. Некоторые сотрудники второго уровня должны быть так же квалифицированы, как и сотрудники третьего уровня.
  • Знание сетей, серверов и приложений. Организации второго уровня должны быть способны решить инциденты и проблемы по всему спектру технологий, используемых в компании.

Третий уровень поддержки

Этот уровень поддержки обычно относится к группе разработки приложений и сетевой инфраструктуры.

Роли
  • Планирование и проектирование ИТ-инфраструктуры. Обычно группа поддержки третьего уровня играет небольшую роль в управлении инцидентами и управлении проблемами, так как такие организации главным образом заняты планированием и конструированием ИТ-инфраструктуры. В этом качестве их цель состоит в реализации бездефектной инфраструктуры, которая не является источником проблем и инцидентов.
  • Последний рубеж в эскалации. Если инцидент или проблема оказывается выше возможностей группы поддержки второго уровня, то группа поддержки третьего уровня принимает ответственность за поиск решения.
Обязанности
  • Решение инцидентов, переданных со второго уровня. Так как большинство инцидентов вызывается известными ошибками, то очень немного инцидентов (5%) проходит через второй уровень на третий. Третий уровень отвечает за решение всех инцидентов, которые к ним поступают.
  • Участие в деятельности по управлению проблемами.Третий уровень поддержки задействован в поиске причин, способов обхода и устранения ошибок.
  • Реализация мер по устранению ошибок из инфраструктуры. У третьего уровня значительная роль в планировании, конструировании и реализации проектов по устранению недостатков инфраструктуры. Выполнение этих проектов должно быть согласовано с обычной работой по развитию инфраструктуры для достижения нужного баланса.
Способности и навыки
  • Эксперты в соответствующих областях. Команды третьего уровня должны быть экспертами, которые планируют и проектируют ИТ-инфраструктуру.

Процессы

Можно выделить три основных процесса, связанных с управлением инцидентами и управлением проблемами:

  • процесс управления инцидентами
  • процесс контроля проблем
  • процесс контроля ошибок

Эти основные процессы присутствуют практически во всех передовых организациях, хотя могут иметь и другие названия.

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

Данный процесс сфокусирован на скорейшем восстановлении прерванного сервиса. В таблице 1 приведены основные параметры этого процесса, а на рисунке 1 показана диаграмма его работы.

Таблица 1. Параметры процесса

Параметр процесса

Описание

Назначение

  • Восстановить сервис для конечного пользователя, поддерживая высокую степень удовлетворенности

Владелец

  • Команда поддержки первого уровня

Вход

  • Обращение пользователя с сообщением о прерывании сервиса

Выход

  • Сервис восстановлен
  • Конечный пользователь оповещен
  • Создана запись об инциденте
  • Создана запись о возможной проблеме

Типичные числовые параметры

  • Количество открытых инцидентов, сгруппированных по уровню серьезности, прошедшему времени, группам ответственности
  • Количество инцидентов, сгруппированных по времени (помесячно/поквартально)
  • Количество инцидентов, переданных и решенных на каждом уровне
  • Среднее время, затраченное на инцидент в каждой группе
  • Среднее время восстановления сервиса
  • Процент инцидентов, решенных в заданное время
  • Инциденты по технологиям
  • Инциденты по пользовательским группам

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

Рисунок 1. Модель процесса

Процесс контроля проблем

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

Таблица 2. Параметры процесса управления проблемами

Параметр процесса

Описание

Назначение

  • Определить причину проблемы и способ временного или постоянного решения

Владелец

  • Команда поддержки второго уровня

Вход

  • Инцидент высокого уровня серьезности
  • Инциденты, переданные для решения на третий уровень поддержки
  • Инциденты, выделенные на совещании

Выход

  • Документированная причина
  • Сообщение о временных решениях на все уровни поддержки

Типичные числовые параметры

  • Количество проблем, сгруппированных по времени (помесячно/поквартально)
  • Количество проблем, где анализ причин отложен
  • Количество открытых проблем (причина не выявлена)
  • Среднее время, затраченное на рассмотрение проблемы на каждом уровне
  • Среднее время для определения причины
  • Проблемы по технологиям
  • Проблемы по пользовательским группам

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

Процесс контроля проблем

Рисунок 2. Модель процесса контроля проблем

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

  1. Если у вас достаточное количество проблем, то назначьте постоянную команду. Иначе создавайте команду при появлении проблемы, во многом также как формируется команда под какой-либо проект;
  2. Команда почти всегда должна быть с междисциплинарным опытом и знаниями. И это конечно зависит от природы возникшей проблемы;
  3. Следует давать оценку времени на определение причины (разрабатывать план проекта) в момент появления проблемы. В соответствии с этой оценкой следует измерять прогресс в деятельности команды.

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

Процесс контроля ошибок

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

Таблица 3. Параметры процесса управления ошибками

Параметр процесса

Описание

Назначение

  • Оповещение о методах обхода известных ошибок и обеспечение исправления этих ошибок командами разработки

Владелец

  • Команда поддержки второго уровня

Вход

  • Проблемы, причины которых выявлены
  • Известные ошибки, реализованные через процесс управления изменениями

Выход

  • Документированные методы обхода ошибок для различных групп поддержки
  • Приоритезированный список проектов по исправлению известных ошибок

Типичные числовые параметры

  • Количество известных ошибок
  • Количество инцидентов, вызванных известными ошибками
  • Количество проектов, основанных/реализованных для исправления известных ошибок
  • Стоимость всех проектов по исправлению известных ошибок

Процесс контроля ошибок

Рисунок 3. Модель процесса контроля ошибок

Взаимодействия

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

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

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

Эскалация

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

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

Функциональная эскалация

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

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

Таблица 4. Матрица эскалаций

Уровень инцидента

Описание

Срок решения

Начальный уровень

Первая эскалация

Вторая эскалация

Третья эскалация

1

Свыше 50 пользователей не могут выполнять бизнес-транзакции

2 часа

1-ый уровень поддержки

0 минут

2-ый уровень поддержки

30 минут

3-ий уровень поддержки

30 минут

1-ый менеджер

Экстренное совещание

2

От 10 до 49 пользователей не могут выполнять бизнес-транзакции

4 часа

1-ый уровень поддержки

0 минут

2-ый уровень поддержки

60 минут

3-ий уровень поддержки

60 минут

1-ый менеджер

Экстренное совещание

3

От 1 до 9 пользователей не могут выполнять бизнес-транзакции

8 часов

1-ый уровень поддержки

30 минут

2-ый уровень поддержки

120 минут

3-ий уровень поддержки

120 минут

1-ый менеджер

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

Иерархическая эскалация

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

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

Отчеты и совершенствование процессов

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

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

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

Такие отчеты позволяют руководителям принимать решения о распределении ресурсов, направлении усилий персонала. Регулярное использование параметров типа:

  1. Среднее время обработки карточек на каждом из уровней
  2. Количество карточек, переданных и решенных на каждый из уровней, могут помочь выявить слабости ИТ-инфраструктуры

Наконец жизненно необходимый набор отчетов, типа:

  1. Процент инцидентов, решенных в заданные сроки
  2. Среднее время на восстановление сервиса, позволяет взаимодействовать ИТ-организации со своими потребителями и соотносить достигнутый уровень производительности с целевым уровнем сервиса

Заключение

Разработка процессов и процедур управления инцидентами проводится многими организациями, но далеко не все эти организации делают то же самое для управления проблемами. Часто это происходит из-за недостаточно ясного понимания характеристик этих двух видов деятельности. Управление инцидентами — простейший вид деятельности для понимания, поскольку он просто создает механизм для реагирования на прерывания сервиса. Поскольку «визгливое колесо всегда будет смазано», то управление инцидентами развивается достаточно быстро. Однако для развития управления проблемами часто имеется меньше поводов.

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

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

www.inframanager.ru

3 пары похожих терминов ITIL / Блог компании ИТ Гильдия / Хабр

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

В этой статье мы попытаемся разграничить три пары похожих терминов:

  • Инцидент и проблема
  • Управление инцидентами и управление проблемами
  • Service desk и Help Desk
На основе примеров покажем, для чего нужен каждый из них.

/ Flickr / Dennis / CC

Инцидент и проблема

IT-специалист и автор тренингов по ITIL Майкл Скарборо (Michael Scarborough) подчёркивает, что между терминами установлена следующая зависимость: проблема — причина, инцидент — следствие.

Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. Когда мы говорим «разрешили инцидент», это значит, что временно восстановили какую-то услугу (на 10 лет или всего на 1 минуту). То есть очень вероятно, что подобная ситуация повторится в будущем.

Проблема же, это причина возникновения инцидентов. Эксперт в области ITSM профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему», который вы задаёте себе.

Посмотрим на примеры, которые приводит директор по маркетингу компании Hornbill Питер Саммерс (Peter Summers).

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

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

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

Другой пример: вы едете на лысой резине — это проблема. Если вы продолжите её игнорировать, вероятность возникновения инцидента будет расти, покрышка, вероятно, лопнет.

Чтобы упростить вопрос с разграничением значений этих двух терминов, Филип Юсон (Philip Yuson), генеральный директор Concept Solutions Corporation, рекомендует задавать следующие вопросы:

  • Сервис недоступен?
  • Ухудшилось ли качество услуг?
  • Пострадали ли бизнес-процессы?
  • Пострадало ли качество предоставления услуги?
Если вы ответили «да» на один из этих вопросов, скорее всего, вы столкнулись с инцидентом.

Incident Management и Problem Management

Мы уже выяснили, чем отличаются инцидент и проблема, поэтому разграничить эти два процесса будет проще. ITIL определяет эти два термина следующим образом:

Управление инцидентами — управляет жизненным циклом всех инцидентов. Цель: скорейшее восстановление ИТ-услуги для пользователей.

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

Посмотрим на примеры от специалистов Microsoft. Представим сценарий: к специалисту техподдержки обратился пользователь, который не может просмотреть электронное письмо из-за ограничений. Саппорт создаёт новый инцидент с помощью шаблона e-mail incident, чтобы быстро разрешить ситуацию и обрабатывать похожие случаи в будущем.

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

Для большей ясности приведём пару примеров из жизни. Управление инцидентами похоже на работу пожарных. Они приходят на место происшествия и стараются максимально эффективно погасить огонь. То же самое происходит при управлении инцидентами. Возобновить работу инфраструктуры нужно быстро.

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

Service desk и Helpdesk

Для начала вновь заглянем в официальную терминологию ITIL.

Service Desk — единая точка контакта (SPOC) между поставщиком услуг и клиентами. Функции: управляет инцидентами, запросами на обслуживание.

Help desk — точка контакта для пользователей. Функции: регистрирует инциденты.

Термин «служба поддержки» часто употребляется как синоним службы Service Desk, что является главной причиной путаницы в терминах. Крис Коффи (Cris Coffey), менеджер по маркетингу компании BMC Software, который работает на рыке Help Desk уже 20 лет, выделяет следующие различия между двумя этими службами.

Service Desk: полностью интегрируется с другими ITSM-процессами, помогает организации соответствовать соглашениям об управлении уровнем услуг, интегрируется с базой данных управления конфигурациями и процессом управления активами.

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

Посмотрим, как это выглядит на практике. Пример работы Help Desk: драйвер для принтера Джо сломался, а ему нужно распечатать копии документов до 10 часов. Help Desk поможет Джо восстановить работу принтера или найдёт другой способ получить распечатки вовремя. Задача службы — сделать так, чтобы распечатки были в руках у Джо до 10 часов.

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

Напоследок кратко обобщим все разобранные моменты:

Инцидент и проблема
  1. Проблема — причина, инцидент — следствие.
  2. Инцидент устраняем сразу же. После него ищем источник проблемы разрешаем её.
Управление инцидентами и управление проблемами
  1. Управление инцидентами работает быстро, а управление проблемами — тщательно.
  2. Устраняем проблему — предотвращаем инциденты, связанные с ней.
  3. Устраняем инцидент — помогаем пользователю продолжить работу.
Help Desk и Service Desk
  1. Service Desk — стратегия, Help Desk — тактика.
  2. Service Desk работает для сотрудников и для клиентов, а Helpdesk только для клиентов.
  3. Service Desk концентрируется на процессах и делает всё, чтобы они соответствовали ITIL.
  4. Help Desk концентрируется на помощи. Его главная задача — решить задачи клиента.
P.S. Еще пара материалов из нашего блога:

habr.com

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.

smartsourcing.ru

«Инцидент менеджмент» и суровая реальность

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

Нормативные ограничения

Сегодня существует несколько порталов, предназначенных для решения городских проблем. В Санкт-Петербурге функционирует портал «Наш Петербург», в Москве «Наш город», на котором заявляется, что за время работы ресурса удалось решить практически три миллиона проблем. Есть и негосударственные аналоги: «Красивый Петербург», «iGrajdanin» и многие другие. И государственные, и негосударственные порталы работают по одному принципу. Каждая проблема оформляется как запрос и направляется в профильный госорган, который за нее отвечает. Отличие лишь в том, что на государственных порталах работу осуществляют чиновники, а в частных инициативах запрос оформляется юристами и направляется не от имени автора проблемы на сайте, а от сотрудника организации, или же от СМИ, как это делают в проекте РосОтвет.

Работу с запросами граждан регулирует Федеральный закон «О порядке рассмотрения обращений граждан Российской Федерации» № 59. По нему госорган обязан рассмотреть обращение гражданина в течение 30 дней, обращение СМИ — в течение 7 дней. Госорган не может проигнорировать запрос, что-то чиновники должны ответить. Если в обращении гражданин описывает какую-либо проблему, иногда госорганы стараются ее решить, особенно, если речь идет о каком-то резонансном вопросе.

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

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

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

Нормативные трудности — не единственные ограничения новой системы, уже сейчас очевидны технические сложности, с которыми в регионах придется как-то работать.

Технические сложности

Реализацией проекта, по версии источников РБК, занимается «Медиалогия», у которой есть собственный продукт «Медиалогия СОЦМЕДИА». Из имеющихся описаний того, как будет работать «Инцидент менеджмент», становится понятно, что эти два продукта будут очень похожи, а значит государственная система мониторинга унаследует все болячки своего старшего брата.

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

— Много мусора. Пока система «Медиалогии» не так хорошо справляется с фильтрацией сообщений от ботов. Да, явные аккаунты вычисляются, но с каждым годом боты становятся все больше похожи на обычных пользователей: оригинальные фотографии, посты, социальная активность. Соответственно, все это будет попадать в мониторинг власти и усложнять процесс работы с данными.

— Позитив и негатив — не главное. «Медиалогия» делает ставку на анализ тональности сообщений, когда в индустрии Big Data идет тренд на вычленение и анализ фактов из сообщения. По сути дела, госорганам не так важно, понравилась ли новая дорога горожанам или нет, важно понять, что именно не понравилось, в чем есть проблемы. И пока есть сомнения, что в новой системе анализ фактов будет автоматизирован.

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

Смещенная линия коммуникации

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

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

В таком случае проблемы города будут обсуждать низкомотивированные и незаинтересованные представители госорганов с одной стороны, а с другой — узкая группа населения, которая не является репрезентативной выборкой жителей города.

Перспективы

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

При помощи Beg Data уже ищут террористов, преступников и занимаются мониторингом стратегических вопросов, теперь покрытие расширяется на публичное пространство. В скором времени лучше своего потребителя будут понимать не только коммерческие структуры, которые давно анализируют данные о пользователях, но и государство, которое также является одним из поставщиков услуг. Развитие этой системы переведет общение «общество — государство» на новый уровень.

Михаил Карягин, политолог

actualcomment.ru

Что такое процесс управления инцидентами? Описание, определение по ITIL

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

Управлять инцидентами просто

Основные задачи процесса управления инцидентами:

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

Процесс управление инцидентами акцентируется исключительно на устранении последствий сбоев в ИТ-услугах. Поиском и анализом причин возникновения инцидентов занимается процесс управления проблемами.

Управление инцидентами (Incident management) по ITIL

Работа с пользователями и регистрация их обращений в службу Service Desk – непосредственная часть процесса управления инцидентами. Поэтому очень часто в управление инцидентами включают также обработку запросов на обслуживание, которые являются частью стандартных ИТ-услуг, предоставляемых пользователю: изменение прав доступа, предоставление информации, установки и обновление стандартного набора ПО и др. Любые обращения пользователей, не входящие в состав ранее согласованных ИТ-услуг, обрабатываются в рамках процесса управления изменениями.

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

  • Снизить количество инцидентов, влияющих на работу пользователей.
  • Организовать закрытие инцидентов в сроки согласованные в SLA.
  • Оптимизировать ИТ-ресурсы компании.
  • Повысить удовлетворенность пользователей и заказчиков ИТ-услуг.
Запрос демо ITSM 365 Подписка на обновления блога Подписаться

itsm365.ru

Управление инцидентами в IT может быть не только про IT / Хабр

От переводчика: любопытная статья Стюарта Рэйнса с предложением, как ИТ повысить свою ценность в рамках компании, перейдя от управления инцидентами в ИТ к управлению инцидентами в бизнес процессах компании.

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

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

Что такое инцидент?

Наиболее популярный сейчас в мире сборник практик по управлению ИТ услугами — ITIL даёт такое определение инцидента:

«Незапланированное прерывание ИТ услуги или ухудшение качества ее предоставления…»

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

Мой клиент же определяет инцидент по другому. Инцидент — это

«любое отклонение продукта бизнес процессов в сторону нежелательного для бизнеса результата.»

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

Кто может предложить действие для решения инцидента?

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

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

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

Когда закрывать инцидент?

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

По рекомендациям ITIL инцидент должен находиться в состоянии “решен” до того момента, пока заказчик не подтвердит, что его можно закрыть. На практике же многие ИТ организации автоматически закрывают инциденты, если заказчики не дают им обратную связь о результате в течение определенного времени.

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

Какие отчеты об инцидентах создавать?

Обычно отчёты управление инцидентами сосредоточены на том, как быстро ИТ организация решает инцидент. Это может быть полезным при планировании и управлении совершенствованием ИТ и показывает, на сколько выполняются обязательства перед заказчиком по уровню обслуживания услуги (Service Level Agreement, SLA). Но для бизнеса такой подход ценности практически не несет.

Когда Вы переопределите инцидент на более “бизнесовый” вариант, то с большей вероятностью будете создавать отчётность, несущую ценность для бизнеса:

  • На сколько значительные негативные последствия были в бизнес процессе?
  • Какие причины наиболее часто вызывают инциденты? (Часто проблемы с ИТ будут не при чем).
  • Где в процессе решения инцидентов случаются наиболее длительные задержки?
Все эти данные могут помочь планировать и управлять совершением того, как управляется бизнес. А также на сколько хорошо ИТ помогает бизнесу.

Заключение

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

Источник изображения: miningcamper

habr.com