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

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

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

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

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

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

Если одна из tension-метрик игнорируется (значение 0%), общий KPI, рассчитанный как геометрическое среднее, становится равным 0%, независимо от значения второй метрики. Это отражает критическую проблему: работа не соответствует требованиям, так как баланс между конфликтующими целями нарушен. Например, высокая своевременность при нулевой результативности означает, что инциденты перенаправляются без решения, что усугубляет нагрузку на систему и снижает качество обслуживания.

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

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

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