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

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

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

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

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

Процессы EDM02, EDM03 и EDM04 в COBIT 5 совместно обеспечивают оценку, направление и мониторинг системы управления ИТ по трём основным направлениям, которые важны для заинтересованных сторон: EDM02 отвечает за формирование ценности и обеспечение получения выгод, EDM03 — за оптимизацию рисков, EDM04 — за оптимизацию использования ресурсов. Эти процессы ориентированы на руководство системой управления ИТ, которая включает в себя набор из 32 процессов.

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

Для определения потоков, запускаемых на различных этапах путешествия заказчика, необходимо провести детальный анализ взаимодействия между этапами путешествия и видами деятельности потоков создания ценности. Нужно выявить, на каких этапах происходит предъявление спроса со стороны потребителя (заказчика или пользователя) и какие потоки при этом активируются. Например, на этапе Offer, когда собираются требования к услуге, запускается поток Engage. На этапе Co-create, когда пользователь обращается за решением инцидентов, запускаются соответствующие потоки предоставления услуги. Для точного определения таких связей требуется пошагово пройти путешествие заказчика и сопоставить каждый этап с соответствующими потоками.

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

Ценность прямого измерения удовлетворенности заказчика услугами заключается в том, что оно дает оценку степени соответствия результатов деятельности поставщика услуг непосредственно из уст заказчика, обеспечивая более точную обратную связь. Подход позволяет учитывать как warranty (гарантийные показатели качества обслуживания), так и utility (полезность услуги), что не всегда отражается в традиционных количественных показателях SLA. Таким образом, поставщик услуг получает более полное представление о реальном восприятии качества его услуг.