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

Безвыходные инциденты

Опубликовано 26 сентября 2012
Рубрики: ITIL, ITSM, Service Desk, Управление инцидентами
Комментарии

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

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

Однако есть вопрос, что делать с такими инцидентами. Можно оставлять их без внимания. Но есть ряд рисков. Вот основные:

  • злоупотребление данным кодом закрытия со стороны ИТ-специалистов (лень искать решение, спишем все на то, что решения нет)
  • недовольство со стороны пользователей 

Таким образом, желательно контролировать подобные инциденты, — например, силами менеджера процесса, который сможет анализировать:

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

А что вы делаете с подобными инцидентами? Есть ли у вас такой код закрытия?

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Вячеслав Потов

    У нас я бы руководился следующей логикой.

    Инцидент — это прерывание или деградация сервиса.

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

    Классификация при этом была бы «Insufficient user training», так как ответственный key user или Application owner не провёл разьяснительную работу что это не баг а фича.

    (В данном случае вина не возлагается на пользователя)

    Если фича вызывает недовольство и потенциально виден impact, то надо открыть проблему, классифицировать её как Known Error (надеюсь мы знаем, почему так разработано приложение).

    После этого она страновится ответственностью Application support или Application owner, которые дальше решают как с этим жить. Дорабатывать, жить с этим.

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

    • Вячеслав Потов

      Прошу прощения за использование английского.

  • Vladimir Kapustin

    По закрытиям инцедентов у нас происходит анкетирование пользователей.

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

  • Степан

    Всё таки не очень очевидна необходимость такого кода закрытия.

    Если мы объяснили пользователю, что приложение так работать не может, то это равносильно консультации (и закрывается с теми же параметрами, что и любая консультация в данной компании)

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

  • Альберт

    Персонифицируйте формулировку вместо «Нет решения» например «Не могу решить». Все равно закрывает инцидент конкретный сотрудник. Менеджер на регулярной основе должен анализировать инциденты с таким статусом. Далее уже либо сотрудника обучать, либо пользователя.

    Вообщем без контроля не обойтись.

    • Андрей Загорский

      Едва ли пользователю понравится такой код закрытия «Не могу решить».

      Возникают вопросы о квалификации техподдержки.

      • Альберт

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

  • Pavel Solopov

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

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

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

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

    • Павел, действительно иногда вводят два кода закрытия: «Решено» и «Решено с применением обходного решения». Например, когда планируют что-то дальше делать с обходными решениями.

      • Pavel Solopov

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

        • Ну, это у кого как мозг устроен 🙂 Некоторые ставят подменный принтер и забывают о том, что он подменный. Стандартной архитектурой данного рабочего места этот принтер не становится.

          • Pavel Solopov

            Если забывают, то значит просто речи про какую-то архитектуру и не идёт. Архитектура строится по принципу «как придётся», в этом случае и обходных решений быть не может. Точнее разделить обходное решение и решение не возможно.

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

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

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


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT