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

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

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

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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

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

Принцип "Упрощайте" (Keep it simple), описанный в ITIL Practitioner Guidance 2016 года, был расширен в ITIL 4 до формулировки "Простота и практичность" (Keep it simple and practical). Это изменение отражает важность не только простоты решения, но и его практической применимости. В ITIL 4 подчеркивается, что слишком сложные решения затрудняют внедрение и эксплуатацию, однако простота ради простоты тоже не имеет смысла, если решение не решает поставленные задачи. Таким образом, акцент смещен с простого упрощения на поиск оптимального баланса между простотой и практической пользой.

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

Эффективность обратной связи определяется двумя основными критериями: готовностью клиента предоставлять обратную связь («отзывчивость») и полезностью высказанных клиентом замечаний для организации. Эти критерии образуют четырехсекторную модель, где комбинация высокой/низкой отзывчивости и высокой/низкой полезности создает разные зоны взаимодействия: «Мертвая зона», «Hard Candy», «Токсичная зона» и идеализированный вариант «Клиенты мечты». Основная цель системы — идентифицировать тип обратной связи и применять соответствующие стратегии обработки для каждой зоны.