Чтобы определить, является ли сбой RAID-массива инцидентом, нужно учитывать конкретную конфигурацию и условия, при которых массив считается работающим нормально. Например, в RAID 1+0 выход из строя одного диска в зеркале не считается инцидентом, если это не влияет на функциональность массива и его отказоустойчивость остается в допустимых пределах. Однако выход из строя второго диска в том же зеркале может привести к потере надежности и уже будет инцидентом. Важно определить, какие состояния являются нормальными для конкретной системы на основе технических спецификаций, и только после этого принимать решение о классификации происшествия.

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

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

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

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

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

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

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

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

Процесс Управления запросами на обслуживание (RFF) не является основным для обработки запросов о статусе инцидента потому, что ответственность за обеспечение прозрачности и коммуникацию информации о статусах инцидентов возложена на процесс Управления инцидентами (INC). Хотя RFF может использоваться в качестве канала коммуникации для передачи информации по запросу пользователя, он не несёт первичную ответственность за организацию такой коммуникации. INC должен спроектировать систему коммуникации и выбрать оптимальную комбинацию каналов (проактивные – автоматическое оповещение и реактивные – выдача информации по запросу), включая использование RFF в качестве одного из возможных механизмов. Использование RFF как основного процесса для подобных запросов приведёт к снижению ответственности INC за качество коммуникаций и, как следствие, к снижению общего качества обслуживания.