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

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

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

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

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

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

  1. Николай

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

    1. Игорь Гутник Автор

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

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

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

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

        1. Игорь Гутник Автор

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

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

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

          1. Андрей

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

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

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

          2. Николай

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

  2. Владимир

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

      1. Владимир

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

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

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

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

    1. Игорь Гутник Автор

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

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

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

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

  4. Игорь Гутник Автор

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

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

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

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

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

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

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

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

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

ОКТ
22
ОКТ
29