Многие ценные идеи, инициативы и поручения теряются, потому что они не были записаны. Даже если решение было принято на совещании, без письменной фиксации оно может быть забыто или неверно истолковано. Письменная фиксация решений с указанием ответственных и сроков обеспечивает прозрачность процесса, служит основой для контроля и позволяет избежать недопонимания между участниками процесса. Это особенно важно при работе с несколькими людьми, где информация может искажаться при передаче от одного сотрудника к другому.

Основной базовый набор ключевых метрик DevOps включает: время нахождения идеи в бэклоге (пока не взяли на реализацию), время прохождения задачи от начала работы до выпуска в продуктивную среду, долю выполненных задач, которые принесли ожидаемую пользу, и предсказуемость выполнения взятых на себя задач за определенные временные периоды. К этому базовому набору можно добавить дополнительные метрики, такие как velocity, MTTR (среднее время восстановления), MTBF (среднее время наработки на отказ) и расход ресурсов на устранение дефектов и инцидентов. Однако важно не количество метрик, а то, что они дают объективную картину ситуации и помогают в принятии решений для уменьшения времени выпуска продукта (lead time).

Парадигма ITSM традиционно воспринималась как более формализованный и структурированный подход, тогда как DevOps и Agile фокусируются на гибкости и скорости. Однако современные версии ITSM (такие как ITIL 4) активно интегрируют принципы Agile и DevOps, сочетая структурированное управление услугами с гибким подходом к развитию ИТ-систем. Это проявляется в упоре на сотрудничество между командами, непрерывное улучшение, автоматизацию процессов и сокращение времени вывода новых сервисов на рынок. Современное понимание ITSM не противоречит Agile и DevOps, а предоставляет рамки, в которых эти подходы могут эффективно функционировать, сохраняя контроль над качеством и стабильностью услуг.

Для корректного применения метрики результативности необходимо соблюдение следующих условий: переназначение инцидентов должно использоваться только для функциональной эскалации, то есть передачи инцидентов на более высокий уровень экспертизы, а не для других целей (например, возврата на Service Desk при закрытии инцидента или последовательного выполнения работ разными группами). Также важно, чтобы при отказе пользователя от решения инцидент возвращался именно той группе, которая предоставила решение, а не перенаправлялся на другие группы (например, не на Service Desk).

Определение типа услуги зависит от того, взаимодействует ли с ней конечный потребитель напрямую. Если услуга предоставляется заказчику непосредственно и на нее заключается SLA - это бизнес-услуга. Если услуга работает в качестве внутреннего компонента, который необходим для функционирования бизнес-услуги, но клиент с ней не взаимодействует напрямую - это поддерживающая услуга. Важно учитывать контекст: одна и та же услуга может быть бизнес-услугой для одного потребителя и поддерживающей для другого.

Парадигма ITSM способствует повышению качества ИТ-услуг через введение стандартизированных процессов, регламентирующих все аспекты предоставления сервисов. Это включает чёткие процедуры регистрации и обработки инцидентов, управление изменениями для минимизации рисков, проактивное управление проблемами для предотвращения повторяющихся сбоев, установление SLA-соглашений с измеримыми показателями качества. Кроме того, ITSM предусматривает постоянный мониторинг и анализ метрик, что позволяет выявлять узкие места и постоянно улучшать процессы. Такой системный подход обеспечивает предсказуемость и стабильность ИТ-сервисов.

Некоторые элементы продуктового подхода полезны даже когда настоящего продукта нет. Сюда входит концентрация на ценности, а не на функциональности; четкое определение границ и зависимостей между командами; использование дорожных карт, даже если они изначально представляют собой просто планы релизов функциональности; организация рабочего процесса вокруг создания ценности, а не просто процесса разработки ПО; формирование продуктовых (а не проектных) команд; применение продуктовых метрик, даже если вместо стандартных MAU/DAU измеряется, например, уровень использования функциональности. Эти элементы могут принести пользу, даже если не все критерии продуктового подхода выполняются, и не имеют негативных последствий при правильной реализации.

Роль "Практик изменений" в ITIL V3 частично соответствует понятию "Координатор изменений", используемому на практике, но не в полной мере. В описании обязанностей практика изменений упоминаются мониторинг и проверка (reviewing) корректности выполнения работ по изменению, но не прямо указана задача по координации действий участников. Координация изменений упоминается в ITIL не в разделе про роли, а в описании активностей процесса, и её выполнение может быть возложено на разные лица: менеджера процесса, практика изменений или участников CAB. Поэтому многие организации на практике выделяют отдельную роль координатора изменений для обеспечения сквозной ответственности, что не формализовано в самом стандарте ITIL.

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

ITSM-проекты редко реализуются по гибкой методологии из-за их комплексности и масштабов конечных целей, которые затрудняют детальное дробление задач ('шинковку'). Это приводит к периодам, когда требуется участие большинства заинтересованных сторон, например, для проведения интервью или детальной проработки концептов. В отличие от гибких методологий, где изменения внедряются малыми шагами, в ITSM необходим одновременный доступ к множеству сотрудников, что усложняется их плановыми отпусками.