status

Статус в ITSM используется как формализованное описание того, в каком состоянии находится сущность прямо сейчас, и какие допустимые состояния вообще определены для неё в рамках выбранного жизненного цикла. Сущностью может быть запись в инструменте управления услугами (например, инцидент, проблема, запрос на обслуживание, запрос на изменение), а также объект управления (например, конфигурационная единица). Статусы задают понятные правила движения работы: кто и когда должен подключаться, какие действия разрешены, какие ожидания по срокам применимы, и в какой момент работа считается завершённой. Корректно определённые статусы поддерживают измерение и отчётность, помогают управлять очередями, автоматизировать маршрутизацию и уведомления, а также обеспечивать прозрачность для заказчика и пользователя. При этом статус описывает именно состояние, а не причину, не приоритет и не результативность. Он обычно является частью модели процесса или процедуры и должен быть одинаково понимаемым всеми командами поддержки и поставщиком услуги, иначе данные по загрузке и времени обработки становятся несопоставимыми. Вне области применения термина находятся содержательные оценки качества решения, расчёт метрик, анализ первопричин и любые бизнес-решения о целесообразности услуги; статус лишь фиксирует состояние, а не объясняет его.

Статус часто путают с этапом процесса, степенью готовности или с полями классификации, такими как приоритет, категория или риск. Например, «Высокий приоритет» не является статусом инцидента; это атрибут, который может влиять на целевые времена, но не описывает состояние работы. Ещё одна типичная ошибка — делать статусы слишком детальными и «подменять» ими действия или ответственных: статусы вида «На согласовании у ИБ» или «Ждём сеть» выглядят удобными, но быстро приводят к разрастанию справочников и невозможности устойчивой аналитики. Лучше отделять статус от причины ожидания и фиксировать причину отдельным полем или комментарием, оставляя статусы стабильными и минимально достаточными. Также важно различать статус и факт выполнения: запись может иметь статус «Решён», но оставаться не закрытой до подтверждения пользователем; это разные состояния и разные правила управления. Наконец, статусы должны быть согласованы между практиками: если инцидент связан с проблемой или запросом на изменение, несогласованные жизненные циклы приводят к ситуациям, когда работа «зависает» на стыке команд, и управление инцидентами или управление изменениями теряет управляемость.