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

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

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

Помимо USM (Universal Service Management) и eSCM-SP (eSourcing Capability Model for Service Providers), в тексте упоминается подход, аналогичный eTOM (Enhanced Telecom Operations Map), но адаптированный для более широкого спектра услуг. Автор полагает, что существует потребность в промежуточном варианте между USM и eSCM-SP - уровне сложности, близком к eTOM, но с обобщением на различные виды услуг. Такой подход должен сохранять простоту понимания, присущую USM, но иметь большую детализацию, чем это предлагается USM, и в то же время быть менее сложным, чем eSCM-SP.

Автор считает, что должен существовать промежуточный уровень между USM и eSCM-SP, потому что USM слишком простой, а eSCM-SP слишком сложный для практического применения. Автор видит потребность в подходе, который будет близок по сложности к eTOM, но с возможностью обобщения на различные виды услуг, а не только телекоммуникационные. Такой промежуточный уровень должен сохранить простоту понимания USM, иметь достаточную детализацию, чтобы быть практически полезным, и не быть перегруженным сложностью eSCM-SP, что сделало бы его малоприменимым для многих организаций.

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

Типичный диапазон значения Incident Rate составляет от 0.8 до 1.2 инцидентов в месяц на одного пользователя. Крайние случаи могут достигать 0.4–2.3, но чаще всего величина находится в пределах 0.3–2.0. Для сравнения, совокупное количество всех обращений пользователей (включая сервисные запросы и инциденты) колеблется от 1 до 2 в месяц на одного пользователя.

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

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

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