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

Да, в открытых источниках есть данные за 2012 и 2018 годы, которые демонстрируют различия по отраслям. В 2012 году разрыв между отраслями был значительным: в финансовом секторе — до 4–5 обращений на пользователя в месяц, в здравоохранении — около 0,8–1. К 2018 году разрыв сократился: лидеры снизили нагрузку (до 2,5–3). Это связано с ростом ИТ-грамотности пользователей и улучшением качества услуг. В 2020 году из-за пандемии наблюдался кратковременный рост обращений на 16% из-за массового перехода на удалёнку.

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

Основные ошибки: 1) Сведение управления проблемами к 'медленному' устранению инцидентов без глубинного анализа причин; 2) Отсутствие отдельного потока для проактивного выявления проблем; 3) Непрожитие ролевой модели (например, игнорирование роли координатора проблем); 4) Использование метрик инцидент-менеджмента для оценки проблем; 5) Несоответствие настроек ITSM-системы процессным требованиям. Это приводит к формальному соблюдению процесса и сохранению повторяющихся инцидентов.

Одним из KPI для оценки эффективности коммуникации в процессе Управления инцидентами является «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов». Этот показатель измеряет, насколько эффективно обеспечивается прозрачность процесса: чем меньше у пользователей потребность в повторных обращениях за информацией об уже зарегистрированных инцидентах, тем выше качество коммуникации. Низкое значение этого KPI свидетельствует о том, что пользователи своевременно и в нужном формате получают информацию о статусе инцидентов, что приводит к повышению их удовлетворённости и снижению нагрузки на Service Desk.

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

TTL (Time To Live) — это установленный срок жизни статьи в Базе знаний, по истечении которого информация должна быть перепроверена на актуальность. При приближении срока TTL эксперт переоценивает статью и принимает решение о её продлении в актуальном состоянии или архивации. Это позволяет поддерживать данные в базе свежими и полезными.

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

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

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