lifecycle

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

Жизненный цикл часто ошибочно воспринимают как процесс или поток создания ценности. Процесс и поток создания ценности описывают последовательность работ и их результат (выход/результат), тогда как жизненный цикл задаёт модель состояний и критерии переходов. Например, «в эксплуатации» — это статус услуги, а «предоставление и поддержка» — это набор практик и действий, которые могут выполняться, пока услуга находится в этом статусе. Другая типичная путаница — смешение жизненного цикла услуги с жизненным циклом продукта и релиза: релиз и развёртывание — механизмы доставки изменений, но они не равны смене статуса услуги в портфеле услуг. Распространённая ошибка внедрения — сделать слишком много статусов без чётких определений и правил переходов, из‑за чего команды начинают «перетаскивать» сущности между статусами формально, чтобы закрыть отчётность. Важно заранее определить, кто является органом управления изменениями для ключевых переходов, какие минимальные требования гарантии и требования полезности должны быть подтверждены, и где нужен обзор после внедрения. Ещё один риск — использовать статусы как ярлыки срочности или приоритета: жизненный цикл описывает «где объект находится по развитию/существованию», а не «насколько он важен прямо сейчас».