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

Практика ведения каталога технических услуг и OLA не применима ко всем компаниям, потому что сервисный подход вообще реализован лишь в небольшом количестве организаций, и только к очень небольшой доле этих организаций применима именно практика ведения каталога технических услуг и OLA. Это связано с тем, что такие документы и практики значительно влияют на другие процессы, отношения между подразделениями и оргструктуру, и их введение может быть избыточным или неоправданным в компаниях с простой структурой или без четкого сервисного подхода. О необходимости быть осторожнее с внедрением таких практик уже писали Pink Elephant (около 2006 года) и IT Skeptic (около 2011 года).

Назначение процесса управления уровнем ИТ-услуг заключается в обеспечении качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий. SLM ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Такой подход зафиксирован в стандарте ISO 9001:2000.

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

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

При отсутствии ранее существовавшей документации по управлению активами и конфигурациями рекомендуется использовать название "План управления сервисными активами и конфигурациями" (SACM plan). Это соответствует рекомендациям ITIL v3 2011 (раздел Service Transition, 4.3.5.2). При необходимости, учитывая специфику организации, название может быть адаптировано к таким вариантам как "Положение" или "Регламент". Ключевой момент - документ должен описывать целевой уровень управления сервисными активами и конфигурациями, который организация определяет самостоятельно. Структура документа должна включать разделы по охвату, требованиям, политикам и стандартам, организационной структуре, описанию процедур и связям с другими процессами.

Процесс учета рабочего времени занимает значительно меньше, чем многие предполагают. За весь 2014 год на эту задачу потребовалось всего 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это опровергает распространенное мнение о том, что учет времени может занимать от 5% до 10% рабочего времени.

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

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

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