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

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

Автор полагает, что в книгах ITIL разделение назначения (purpose), целей (goals) и задач (objectives) сформулировано небрежно, потому что: - Отсутствует чёткая и однозначная терминология, что приводит к путанице между этими концепциями. - Не раскрыты практические аспекты применения: например, где и как документировать назначение, цели и задачи процесса. - Нет явного указания на различную стабильность этих элементов (назначение стабильно, цели часто меняются), что влияет на способы их фиксации в документации. - Не указана ответственность по уровням: кто именно (дизайнер, владелец или менеджер процесса) должен работать с каждым элементом. Это заставляет практиков "долго доходить" до понимания этих различий, несмотря на их относительную простоту и важность для практического внедрения ITIL.

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

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

Основные выводы: поток ценности должен представлять собой архитектуру всего бизнеса, включающую все его области и грани, а не только ИТ-аспекты; описание потока должно включать не только процессы 'изменения бизнеса' (change the business), но и процессы его 'функционирования' (run the business); создаваемая ценность должна четко соотноситься с путем потребителя услуг и/или товаров; измерение реальной ценности должно происходить строго по актам потребления этой ценности.

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

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

Каждый процесс домена EDM в COBIT 5 включает три практики, которые следуют единой структуре: оценка, направление и мониторинг. Например, в процессе EDM01 эти практики названы: EDM01.01 «Оценка системы руководства», EDM01.02 «Определение направления развития для системы руководства», EDM01.03 «Мониторинг системы руководства». Такая же трехшаговая структура характерна и для всех остальных процессов домена EDM. При этом объект оценки, направления и мониторинга меняется в зависимости от конкретного процесса.

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