Где в предложении, вынесенном в заголовок, нужно поставить запятую? Речь, конечно же, об инцидентах.
«Переоткрывать» (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»). 
Коллеги, а как решён этот вопрос у вас? И почему именно так?
Добрый день! В нашей Компании инцидент переоткрывается только в случае отклонения решения по обращению пользователем. Т.е. весь маршрут: создание заявки пользователем – регистрация обращения – назначение инцидента – выполнение инцидента – выполнение обращения – запрос подтверждения выполнения у пользователя – отклонение пользователем обращения – переоткрытие инцидента. В каждом инциденте и обращении существует счетчик отклонений. Существует среди KPI и "% отклоненных" – как отдельный и достаточно весомый показатель. Разумеется, есть и механизм апелляции (пользователь часто по ошибке отклоняет обращения). При этом, счетчик времени в инциденте – при повторном открытии – начинается с того места, на котором инцидент был выполнен.