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

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

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

Путаница возникает потому, что формулировка 'заранее авторизованные' может быть неверно истолкована как полное отсутствие необходимости в авторизации стандартных изменений. На самом деле это означает, что авторизация происходит не для каждого отдельного экземпляра изменения, а для модели (процедуры) его выполнения на этапе разработки или пересмотра этой процедуры. Многие специалисты вначале могут подумать, что термин 'заранее авторизованные' означает полное отсутствие какого-либо процесса авторизации, тогда как на практике авторизация просто проводится один раз на уровне процедуры, а не многократно для каждого конкретного экземпляра. Эта недоразумение усугубляется отсутствием четкого объяснения в некоторых источниках о том, в какой момент и как именно происходит эта предварительная авторизация.

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

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

Метрики могут быть использованы для оценки руководителей подразделений через систему взаимосвязанных показателей, отражающих их вклад в процессы. Решение заключается в построении матрицы, где по вертикали расположены функции (отделы, группы), а по горизонтали — процессы. Пересечение функции и процесса означает участие данной функции в реализации процесса, соответственно функциональный руководитель отвечает за предоставление необходимых ресурсов. Процессные метрики сотрудников подразделения связываются с руководителем, назначаются целевые значения, и контролируется их соблюдение. Даже если руководитель формально не несет функциональных обязанностей в процессах (например, не является ответственным в матрице RACI), такой подход стимулирует его к взаимодействию с процессным управлением. На разных уровнях иерархии метрики могут агрегироваться: например, региональные руководители оцениваются по своим метрикам, а руководитель в HQ — по агрегированным метрикам региональных руководителей. Важно, чтобы все используемые KPI были сопоставимы между собой (единая шкала от 0 до 1, одинаковое направление оценки).

Отчётность ради отчётности не соответствует критерию «R» (relevant), так как данные собираются и предоставляются без использования их для принятия решений или изменений в управлении. Наличие измеримых показателей («M») не компенсирует отсутствие релевантности. Это приводит к трате ресурсов на создание отчётов без реальной пользы для организации.

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

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