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

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

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

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

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

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

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

Для интеграции метода 5-Why's в процессы управления проблемами ITIL следует закрепить его как стандартную операционную процедуру при расследовании критических инцидентов. Необходимо обучить сотрудников технике построения причинно-следственных цепочек, разработать шаблоны для фиксации результатов анализа и включить этап применения 5-Why's в регламент по разрешению повторяющихся проблем. Особенно эффективен метод при анализе проблем, требующих глубокого погружения, но не нуждающихся в сложных количественных методах.

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

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