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

В стандарте ISO 20000 обязательные требования содержатся в первой части стандарта, тогда как вторая часть включает рекомендации и практические руководства. Рекомендации во второй части не носят обязательного характера и предназначены для помощи в реализации системы управления услугами ИТ. В случае рассмотрения страницы 20 части 2 упомянутая рекомендация о привязке целевых показателей к приоритету не является требованием и может подвергаться критическому переосмыслению при внедрении практик, например, заимствованных из ITIL.

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

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

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

Каталог бизнес-услуг и SLA (Service Level Agreement) фактически востребован в первую очередь в сценариях массового обслуживания, когда одна услуга может иметь множество заказчиков, каждый из которых имеет свой уровень обслуживания. В случае внутреннего ИТ-подразделения, где обычно присутствует один заказчик (основной бизнес в виде одного или нескольких подразделений), и технические возможности по варьированию уровня услуги ограничены из-за использования единой инфраструктуры, разделение бизнес-услуг от SLA может быть избыточным. Часто каталог услуг в такой ситуации становится фактически «каталогом SLA», а к SLA прилагаются внешние спецификации услуг.

Простота и практичность важны в сервисном мышлении, потому что они напрямую влияют на пользовательский опыт. Анализируя, какие интерфейсы доступны пользователям, как выглядит путь пользователя, и насколько пользователи удовлетворены взаимодействием с сервисом, можно выявить узкие места и возможности для улучшения. Принцип 'Keep it simple and practical' призывает устранять излишнюю сложность и фокусироваться на том, что реально важно для клиента, делая взаимодействие с сервисом максимально удобным и понятным.

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

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

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