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

Существуют два основных варианта интеграции внешних источников данных с CMDB: 1) Перенос данных из внешних систем непосредственно в CMDB; 2) Обеспечение доступа к данным внешних источников через интерфейс CMDB без их физического переноса. Первый подход подразумевает копирование информации во внутреннее хранилище конфигурационной базы данных, тогда как второй вариант сохраняет данные во внешней системе, организуя лишь точку доступа к ним из CMDB.

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

В ITIL рекомендуется использовать «marketing mindset» (маркетинговый способ мышления) при сборе и обработке требований заказчика. Сервис-провайдеру нужно отвечать не на вопрос «Что мы должны предоставить?», а на три ключевых вопроса: какие задачи выполняет заказчик и как ИТ может им в этом помочь; каких результатов хочет достичь заказчик; какие ограничения могут помешать заказчику достичь желаемого и как сервис-провайдер может снять эти ограничения. ITIL отмечает, что у сервис-провайдера часто нет руководств по сбору и обработке требований, что приводит к ситуации, когда заказчики предоставляют требования в произвольной форме без учета процессов. BRM играет ключевую роль в правильной интерпретации требований и обеспечении обратной связи между заказчиком и ИТ-специалистами.

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

Понятие 'менеджер уровня услуг' претерпело существенные изменения от ITILv3 к ITIL 4. В ITILv3 эта роль была более четко определена, хотя и не без противоречий, с указанием на ее функции как интерфейса между поставщиком и заказчиком. Однако в ITIL 4 упоминание этой роли значительно сократилось - она упоминается лишь единожды в главной книге 'Повышение ценности для заинтересованных сторон', но не определяется, а в руководстве по одноименной практике полностью отсутствует. Это отражает общее упрощение ролевой модели в новой версии ITIL.

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

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

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

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