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

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

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

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

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

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

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

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

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

Срочное изменение предполагает определённый временной приоритет, но допускает относительную градацию (например, «очень срочно» или «не так срочно»), что часто ведёт к злоупотреблению термином. Экстренное изменение (emergency) в ITIL — это категория, не подразумевающая градаций: оно требует немедленного выполнения без отлагательств, так как связано с критическими сбоями или угрозами безопасности. Например, если сервис полностью недоступен для клиентов, это emergency — все ресурсы переключаются на его исправление, тогда как «срочное» изменение может укладываться в запланированные сроки.