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

Согласно тексту, эксперты DevOps рекомендуют визуализировать следующие ключевые элементы: поток создания ценности (Value Stream), определение завершения (Definition of Done), ограничение числа задач в работе (WIP Limit), а также ясную картину загрузки ресурсов и ограничений. Эти элементы помогают создать эффективную систему управления работой, обеспечивая прозрачность и понимание процессов всеми участниками.

Основные различия между двумя подходами к управлении релизами: первый подход (в подразделении разработки) рассматривает управление релизами как отдельный процесс, который самостоятельно обрабатывает нестандартные изменения, отвечает за авторизацию изменений на CAB'е и имеет дело только с изменениями в приложениях; второй подход (в подразделении эксплуатации) рассматривает управление релизами как часть процесса управления изменениями, который объединяет несколько изменений в релиз, но не отвечает за авторизацию изменений (это делает управление изменениями), и применяется как к приложениям, так и к инфраструктуре. Первый подход соответствует модели BMC SMPM, второй - ITIL и IBM Tivoli Unified Process.

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

Для определения необходимости и достаточности набора метрик необходимо использовать методологию, которая включает установление назначения процесса и разработку метрик соответствия этому назначению, установление ключевых практик и разработку метрик для этих практик. Дополнительно можно применять Causal Loop Diagram (CLD), который связывает ключевые факторы системы управления и отражает их взаимное влияние. Анализируя элементы CLD и соотнося их с предлагаемыми метриками, можно проверить полноту и адекватность набора метрик, а также определить, покрывают ли они все аспекты управления процессом.

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

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

Раздел Outcomes (верхний левый квадрант) заполняется конкретными результатами, а не названиями процессов. В этом разделе следует указать, что именно будет сделано или получено в ходе проекта. Например, вместо формулировки «внедрение управления изменениями» необходимо написать конкретные достижения: «Сформирован каталог услуг, который включает в себя...», «Заключены SLA с такими-то контрагентами, определяющие такие-то условия», «Организован мониторинг параметров предоставления услуг». Чем конкретнее будут формулировки, тем проще будет впоследствии оценивать успех проекта и принимать решения по его развитию.

Для качественного оказания услуги необходимо: 1) Обеспечивать услугу необходимыми ресурсами - рабочими руками, компетенциями, вычислительными мощностями, финансами и договорными обязательствами третьих лиц; 2) Быстро вносить изменения в услугу по требованиям потребителей с минимальным риском и ущербом; 3) Измерять показатели услуги - мощность, производительность, доступность и эффективность, а также собирать метрики её компонентов; 4) Измерять реакцию потребителей - их удовлетворенность, уровень потребления и текущие требования. Эти направления работы являются основой для понимания текущего состояния услуги и определения необходимых улучшений.

Факторы успеха практик (PSF) в ITIL 4 — это комплексные функциональные компоненты практики, необходимые для обеспечения соответствия практики своему назначению. В отличие от CSF в ITILv3, которые относились к отдельным процессам, PSF охватывают все аспекты управления услугами (Организации и люди, Информация и технологии, Потоки ценности и процессы, Поставщики и партнёры). PSF не являются просто отдельными задачами или видами деятельности, а представляют собой более широкие компоненты, охватывающие различные элементы практики. Например, для практики управления инцидентами PSF включают раннее выявление инцидентов и быстрое и эффективное их решение.