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

В DevOps важно учитывать не только плановую, но и неплановую работу при распределении ресурсов, потому что операционная часть (тот самый 'Ops') требует постоянного внимания к текущим системам и их поддержке. Неплановые задачи, такие как инциденты, исправление дефектов и срочные запросы, являются неотъемлемой частью операционной деятельности и могут возникать в любой момент. Если выделить все ресурсы только на плановую работу, команда не сможет оперативно реагировать на проблемы в эксплуатации, что приведет к снижению надежности системы и удовлетворенности пользователей. Разделение ресурсов позволяет поддерживать баланс между внедрением новых функций и поддержанием стабильности текущих систем.

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

Разделение ИТ-подразделения на две функции — разработку (Change the business) и эксплуатацию (Run the business) — затрудняет управление ИТ-услугами, так как они управляются разными руководителями, имеют разные правила, точки входа для потребителей и взаимодействуют только через процессы управления изменениями и релизами. Это создает барьер для формирования сквозной ответственности за ИТ-услугу, которая должна охватывать все этапы от разработки до эксплуатации. Операционные взаимодействия, такие как управление инцидентами и проблемами, организуются относительно просто, но создание единой системы ответственности требует глубоких изменений в структуре и процессах.

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

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

Оценка успеха внутренних inhouse продуктов сложнее по нескольким причинам: во-первых, пользовательская база значительно уже, что затрудняет сбор репрезентативной обратной связи; во-вторых, между покупателем (спонсором) и непосредственным пользователем часто существует разрыв интересов и потребностей; в-третьих, цикл адаптации и внедрения продукта занимает значительное время (обычно 3+ месяцев); в-четвертых, отсутствует возможность многократного предложения продукта в случае неудачи; в-пятых, финансовая успешность продукта может не напрямую коррелировать с его функциональными характеристиками из-за дискретности продаж и специфики корпоративных решений. Также возникают сложности с получением данных об использовании продукта из-за организационных и технических ограничений внутри компании. Для объективной оценки успеха таких продуктов требуется создание отдельных каналов коммуникации с покупателем и пользователями, измерение TTV (Time-To-Value) - времени достижения ценности продуктом для заказчика, и учет специфики требований разных клиентов.

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

Для получения обратной связи от заказчика в рамках SIP используются формальные и неформальные методы. Формальные методы включают регулярные опросы, где прямо спрашивают, доволен ли заказчик услугой. Неформальные методы включают разговоры 'у кулера' и другие неофициальные способы общения с заказчиком. Важно регулярно собирать мнения о качестве услуги и об удовлетворённости услугой в целом для выявления конкретных причин недовольства или возможностей для улучшения.

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