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

Открыть нельзя переоткрыть

Open_ClosedГде в предложении, вынесенном в заголовок, нужно поставить запятую? Речь, конечно же, об инцидентах.
«Переоткрывать» (reopen, повторно открывать) закрытый инцидент или открывать новый?
Обсуждение этого простого вопроса регулярно возникает на курсах по ITIL, и иногда бывает довольно бурным, поскольку различные организации практикуют различные подходы.
ITIL на этот счёт ограничивается следующими соображениями [ITIL v3 2011, SO, 4.2.5.10]

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

Замечу, что рекомендации ITIL относительно запросов на обслуживание идентичны [ITIL v3 2011, SO, 4.3.5.9].

Доля повторно открытых инцидентов может служить одной из характеристик качества работы процесса управления инцидентами. В идеале закрытие инцидента означает, что он не только решён, но и произведена достаточная проверка того, что решение «сработало». Т.е. рост доли инцидентов, по которым было выполнено переоткрытие, (при прочих равных) означает, что качество работы процесса управления инцидентами снижается – снижается показатель FTR (First Time Resolution – "решение с первого раза [без переделок]"), т.е. процесс становится менее рациональным.

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

Более того, как показано в книге «ITSM. Руководство по измерению», поскольку возврат на доработку влияет на количество обращений, можно создать полную систему оценки, в которой FTR не будет учитываться отдельно. Переоткрытые инциденты будут вносить свой негативный вклад в оценку TCR (Ticket Closure Rate – в нашем контексте, отношение количества решённых инцидентов к количеству назначенных инцидентов [каждый повторно открытый инцидент – это новое назначение, и, следовательно, каждый переоткрытый инцидент увеличивает знаменатель, ухудшая значение TCR]).

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

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

Коллеги, а как решён этот вопрос у вас? И почему именно так?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • Николай

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

    • Николай, спасибо за подробное описание!

      Хотел бы уточнить последовательность. В какой момент времени (на каком шаге описанной последовательности) инцидент закрывается (если есть такая процедура)?

      Ведь если, как указано в описываемой последовательности, мы не смогли пройти этап «подтверждения выполнения у пользователя», то и до этапа «закрытие (closure)» мы не добрались. А раз нет закрытия, то нет и переоткрытия. Просто инцидент вернули на доработку.

      Таким образом, пока не увидел, в какой момент возникает потребность в процедуре переоткрытия инцидента (о которой говориться в посте).

      • Николай

        Игорь,

        Инцидент закрывается автоматически – с закрытием обращения.

        • Ага! Это две разные сущности: инцидент и обращение.

          Тогда предыдущий вопрос звучит так: "Что происходит, когда у пользователя появляются вопросы после закрытия обращения?"

          Или не закрываете обращение, пока пользователь не подтвердит, что его устраивает результат?

          • Андрей

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

            На сколько я понял вопрос: если инцидент полностью закрыт (подтвержден пользователем или по тайм-ауту), при его повторном появлении целесообразно ли открывать имеющийся или создавать новый. 

            В таком случае считаю, что надо создавать новый и связывать его с текущим. Какой вижу профит: не усложняется жизненный цикл инцидента, увеличение количественного показателя инцидентов по однотипному запросы – триггер для управления проблемами, что есть какая-то корневая причина сбоя. Из минусов: разве что артефакты, которые находятся в виде переписки/файлов, но, если они не привели к устранению причины инцидента, то наиболее полезные из них "проблем" так или иначе перенесет в  Базу знаний.

            • Андрей, у меня такая же картина мира.

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

          • Николай

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

  • Владимир

    У нас у обращений есть статус "Выполнено" (решено) и статус "Закрыто" (подтверждено Заявителем или статус ставится спустя 3 рабочих дня после "Выполнено"). Обращение Заявитель может вернуть вработу, пока обращение не перешло в статус "Закрыто". Кол-во возвратов а работу – измеряем. Счетчик времени при повторном открытии не обнуляется (тикает с момента первого обращения): крайний срок решения при повторном открытии, скорее всего, нарушается – это условно правильно, т.к. исполнять всё нужно с первого раза.Пользователей, которые отклоняют по ошибке: у нас – не встрчал/не слышал про такое.

    • Владимир, спасибо! Остаётся вопрос из поста. Что делаете, если пользователь обращается с претензиями по инциденту, который уже закрыли?

      • Владимир

        В зависимости от сути претензии: 1. Открывается новый Инцидент со ссылкой на старый, когда не дочинили и нужно дочинить; 2. Открывается Претензия, со ссылкой на закрытый инцидент, когда починили, но сделали так безобразно/долго и т.д., что плакать хочется – т.е. нужно принимать какое-то административное решение.

        Собственно, выполненный инцидент закрывается в двух случаях: либо Пользователь подтвердил закрытие, либо Пользователь молчал 3 рабочих дня или то кол-во дней, которое ему отвели на молчание.

  • Андрей Щербаков

    В своей практике (внедрение  ITSM решений в 3х разных Компаниях из разных  отраслей) все время приходил к необходимости наличия "переоткрытия". Основная цель не "чтобы все работало" а чтобы "пользователь был доволен", что и определяло необходимость переоткрытия, если пользователь недоволен результатом. С тем, что переоткрытие "косяк ИТ" – согласен. Их нужно считать и сводить к минимуму.

    • Андрей, вторая часть комментария понятна. Спасибо!

      Пока не понял, как реализована процедура «переоткрытия». Это реально переведение статуса инцидента из «Закрыт» в «Открыт»? Или открытие нового инцидента, провязанного к уже закрытому?

      • Андрей Щербаков

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

  • Коллеги, спасибо большое, что поделились!

    Попробую подвести промежуточный итог.

    Процедура переоткрытия (т.е. открытия инцидента, который уже был закрыт) используется только у одного из трёх участников обсуждения. И, если я правильно понял Андрея, такая реализация была выбрана благодаря простоте реализации в  используемой системе автоматизации.

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

    В очередной раз получили подтверждение того, в ITIL-то грамотно описаны все возможные варианты того,  «как оно бывает на самом деле». 😉


Добавить комментарий для Игорь ГутникОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM