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

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

Руководителям, чьи задачи обозначены как R (Responsible - непосредственный исполнитель) в RACI-матрице, рекомендуется делегировать эту работу другим сотрудникам, полностью или частично. Это обусловлено ограниченностью времени руководителя, которое нужно использовать максимально эффективно. Все задачи, которые могут быть выполнены другими членами команды, следует делегировать как можно быстрее. При делегировании важно четко определить, кому и какие именно функции передаются, сохраняя за собой контрольные функции. Это позволяет руководителю сосредоточиться на стратегических задачах, одновременно развивая компетенции подчиненных и создавая резерв исполнителей для ключевых процессов.

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

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

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

В некоторых моделях, например в IBM Tivoli Unified Process, роль координатора изменений называется 'Владелец изменений'. Это создает терминологическую путаницу из-за многозначного использования слова 'Owner' в ИТ-управлении. Слово 'Owner' уже используется в других контекстах, например, в управлении конфигурацией или в бизнес-аналитике, что может привести к недопониманию при коммуникации между различными подразделениями или при использовании разных методологий. Хотя эта неоднозначность не влияет напрямую на функциональные обязанности, она может создавать сложности в обучении персонала и при переходе между различными процессными моделями

Метод EVM нельзя считать полноценной системой измерения успешности завершённых проектов, прежде всего из-за недостатка показателя SPI, который теряет информативность к концу проекта, автоматически становясь равным 1, что не отражает реального соблюдения сроков. Хотя EVM предоставляет ценные метрики для текущего управления проектом, особенно в части контроля бюджета через CPI, его структура не позволяет провести адекватную пост-оценку проекта по временным показателям, что критично для комплексной оценки успешности проекта, включающей качество, сроки и соответствие бюджету.

Одним из примеров программных продуктов, позволяющих правильно настраивать целевые показатели разрешения, является Remedy ITSM Suite. В этом решении возможно привязывать service targets не только к приоритету, но и к уровню влияния, срочности или другим параметрам. Это дает гибкость при настройке правил обработки инцидентов, но при этом не гарантирует правильной работы без грамотной настройки со стороны внедренца. Что касается других популярных систем, например Assyst, информация о реализации этого функционала не упоминается в доступных источниках и требует уточнения.

Помимо пары «среднее + минимум», можно использовать взвешенное среднее, где веса определяются критичностью услуг для бизнеса (например, система учёта продаж может иметь вес 3, а внутренний чат — 0,5). Также подходит подход с процентом услуг, выполнивших SLA на уровне выше целевого (например, 8 из 10 услуг достигли 90%). Для визуализации эффективны термометры, где высота заполнения соответствует среднему значению, а цвет — минимальному (красный при <70%).