В контексте управления изменениями по ITIL V3 термин 'Практик' (Practitioner) относится к роли ответственного за координацию работ по отдельным изменениям, в том числе относящимся к определенной области. Из перечисленных в ITIL V3 ролей (владелец и менеджер процесса, инициатор, практик, авторизующий, участник и председатель CAB) именно практик выполняет функции, которые похожи на обязанности менеджера изменений. В более мелких организациях одна и та же роль 'практик' часто объединяла в себе функции менеджера процесса, владельца процесса, администратора изменений и председателя CAB.

Необходимо: 1) Чётко разделять сценарии создания инцидентов (внешние сбои) и проблем (анализ корневых причин по группе инцидентов); 2) Внедрить отдельные этапы для проблем (диагностика, утверждение решения); 3) Обучить персонал специфике процессов; 4) Настроить ITSM-систему для поддержки уникальных атрибутов проблем (например, этапы обработки); 5) Ввести метрики, отличные от инцидент-менеджмента. Ключевой момент — не создавать запись о проблеме 'для галочки' после инцидента, а запускать полноценный анализ причин.

V-модель наглядно демонстрирует процесс формирования и использования базовых состояний в управлении конфигурациями. На нисходящей ветке модели создаются проектные 'рисованные' базовые состояния различной детализации — от бизнес-требований до технических спецификаций. На восходящей ветке формируются фактические 'фотографии' — зафиксированные состояния объектов. Концепция базовых состояний заключается в возможности сравнения текущего состояния системы с ранее зафиксированным эталоном для определения отклонений. Горизонтальные стрелки модели символизируют процесс принятия решения о соответствии текущего состояния заявленным требованиям

Руководители проектов обладают рядом качеств, делающих их ценными для ИТ-организаций, даже при переходе на гибкие методологии: ярко выраженное системное мышление, позволяющее видеть целостную картину системы, а не отдельные задачи; понимание важности организации работ и умение проводить эффективные совещания с фиксацией решений; способность взаимодействовать с различными людьми, находить компромиссы и убеждать без широких полномочий; глубокие знания о конкретной компании, ее особенностях, распределении власти и ИТ-инфраструктуре; высокая мотивация на достижение результатов, сформированная опытом работы над сложными проектами. Эти качества особенно важны в крупных ИТ-организациях, где необходимо обеспечивать взаимодействие между командами, использующими разные методологии, и управлять сложными взаимосвязями в системе.

Ценность «гарантии» обеспечивает уверенность в том, что добавленная ценность через развитие (utility) не будет обесценена из-за недоступности или некачественной работы услуги. Она измеряется через комбинацию доступности услуги, активной пользовательской базы и управления рисками (снижение негативных или усиление положительных). Ценности «полезности» (основная разработка) и «гарантии» не суммируются, а перемножаются, поэтому игнорирование «гарантии» может обнулить общий результат.

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

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

Да, процесс Управления запросами на обслуживание (RFF) может выступать как один из механизмов информирования о статусе инцидента, функционируя в качестве реактивного канала коммуникации, обеспечивающего передачу информации пользователю по запросу. Однако RFF не должен быть основным процессом для этой задачи, так как ответственность за организацию всего процесса коммуникации, включая выбор и эффективность использования каналов, лежит на процессе Управления инцидентами (INC). RFF может быть частью общей стратегии коммуникации INC, но не её заменой, поскольку использование RFF без чёткого взаимодействия с INC может привести к дублированию функций и снижению качества обслуживания.

При расчете Flow Efficiency возникает вопрос, какое рабочее время учитывать. Если команда состоит из сотрудников с разными графиками работы (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку), возникает сложность выбора календаря. Можно было бы использовать календарь отдельного сотрудника, но в случае совместной работы над задачей это не отражает реальную ситуацию. В результате многие команды прибегают к упрощенным оценкам или договоренностям, которые дают неточные результаты, а не строгий расчет. Это приводит к ситуации, когда формально рассчитанная Flow Efficiency может отличаться от реальной эффективности в несколько раз.

Одним из эффективных подходов к освоению новых практик при внедрении CI/CD является планомерное и ритмичное внедрение изменений в рамках выделенного времени, например, так называемого «налога в 20%». Это означает, что команда регулярно выделяет часть своего времени (примерно пятую часть) для постепенного внедрения необходимых технических изменений и улучшений процессов. Важно, чтобы команда сама проходила этот путь, возможно, с временной сторонней помощью, но при этом самостоятельно осваивала новые практики и отказывалась от старых. Такой подход позволяет команде не только технически реализовать изменения, но и глубоко понимать их ценность. Команда сама себе объясняет, почему теперь она делает что-то иначе — это создает внутреннее принятие новых процессов и устойчивость изменений в долгосрочной перспективе. Постепенное внедрение также снижает стресс от масштабных перемен и позволяет корректировать процесс на ходу, основываясь на получаемом опыте.