Для успешного внедрения модели "Infrastructure as Code" в команде необходимо соблюдение нескольких ключевых условий: необходимо полное внедрение микросервисной архитектуры и использование контейнеров; команда должна быть полностью готова перейти на парадигму неизменности узлов, что означает, что любые изменения происходят не в работающих системах, а путем создания новых конфигураций и замены старых узлов; необходима высокая эксплуатационная компетенция внутренней команды в области настройки middleware и автоматизации процессов; и наконец, необходимо использование систем контроля версий и CMS для управления всей конфигурацией, что позволяет быстро и без потерь восстанавливать инфраструктуру при возникновении проблем. Только при соблюдении этих условий команда сможет добиться максимальной гибкости и масштабируемости инфраструктуры.

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

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

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

Относительные приоритеты бизнеса учитываются при расчете общего показателя качества через использование весовых коэффициентов. Например, при объединении показателей из различных групп услуг (mission-critical, business-critical и обычные) каждой группе присваивается вес, отражающий ее степень важности для бизнеса. При расчете общего интегрального показателя эти веса учитываются в формуле, например, при вычислении взвешенного среднего арифметического. Если mission-critical услуги имеют вес 0.5, business-critical — 0.3, а обычные — 0.2, то их показатели будут пропорционально учитываться в общем результате. Это позволяет управлять акцентами в оценке и более точно отражать стратегические приоритеты бизнеса.

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

При использовании дорожной карты сроки реализации требований определяются иначе, чем при работе только с бэклогом. Сначала обозначаются конкретные целевые состояния и сроки, в которые необходимо достичь этих состояний. Затем определяется состав работ по достижению каждого целевого состояния, включая не только список требований, но и всю деятельность, необходимую для движения к этому состоянию. Под этот состав работ намечается календарь конкретных действий, основанный на опыте команды. Этот подход учитывает не только сложность самих задач, но и дополнительные факторы: время на уточнение требований, согласования, синхронизацию со смежными командами, организацию поставок, согласование приёмочных работ, резервирование ресурсов сервисных команд. Благодаря такому подходу удается дать более точные прогнозные сроки реализации запросов бизнеса, так как виден полный контекст работы над достижением целевого состояния, а не только отдельная задача из бэклога.

FAIR, разработанная независимым консультантом Jack A. Jones, представляет собой структурированный подход к анализу информационных рисков. Методология построена вокруг метафоры, которая демонстрирует, как один и тот же риск может выглядеть по-разному в различных контекстах и с разных точек зрения. В ядре FAIR находится ценная структура факторов, влияющих на вероятность возникновения нежелательного события и размер ущерба, что помогает провести количественную оценку риска. Помимо этого, автор приводит множество практических предостережений, о которых часто не задумываются при стандартных подходах к идентификации и оценке рисков, что делает методологию особенно ценной для практиков.

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

Согласования часто называют «черным ящиком», потому что они содержат множество неочевидных элементов и зависят от множества факторов, которые сложно контролировать извне. В процессе согласования участвует множество людей с различными обязанностями, графиками и приоритетами. Из-за этого становится трудно предсказать, сколько времени займет согласование, какие препятствия могут возникнуть и кто конкретно несет ответственность за задержку. Дополнительно затрудняет ситуацию изменение персонала, необходимость согласования сроков с бизнес-подразделениями и отсутствие единой информационной системы, отслеживающей все этапы процесса. Все это делает согласования непроницаемыми и трудноуправляемыми в контексте общих бизнес-процессов.