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

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

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

Ценности «полезности» (основная разработка) и «гарантии» не суммируются, а перемножаются. То есть, даже при высокой ценности «полезности» (эффективное развитие продукта), если «гарантия» (стабильность, доступность) близка к нулю, общий результат будет нулевым. Например, идеальный продукт, который постоянно падает, не приносит ценности пользователям. Таким образом, обе составляющие должны поддерживаться равномерно.

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

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

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

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

В управлении конфигурациями основным источником информации об изменениях являются процессы управления изменениями, которые фиксируют обновления конфигурационных элементов. В управлении активами данные поступают из различных систем: бухгалтерского учета, складского учета, данных о затратах и ремонте техники, что создает разнородные потоки информации с разными триггерами обновления.

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