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

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

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

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

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

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

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

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

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Вячеслав Потов

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

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

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

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

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

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

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

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

  2. Vladimir Kapustin

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

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

  3. Степан

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

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

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

  4. Альберт

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

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

  5. Pavel Solopov

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

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

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

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

          1. Pavel Solopov

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

  6. Александр Жилинский

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

      1. Александр Жилинский

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27