Портал №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 не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM