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

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

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

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

Затраты на персонал составляют 40-60% операционных затрат на ИТ в российских компаниях. В западных компаниях этот показатель ниже — 30-40%, что связано с более широким использованием аутсорсинга и в среднем более высокой эффективностью труда сотрудников ИТ-подразделений.

PCF (Process Classification Framework) - это открытый стандарт, межотраслевая процессная модель, не привязанная к области деятельности предприятия или сектору промышленности, не зависящая от его размера и местоположения. Он представляет собой общую структуру процессов для любых предприятий, изначально задуманную для систематизации бизнес-процессов и определения общего языка. PCF позволяет идентифицировать процессы на предприятии, используя уже наработанный и накопленный опыт многих компаний; сравнивать между собой эффективность процессов, выполняющихся в разных организациях; заниматься реинжинирингом и совершенствовать процессы. Модель была разработана в 1992 году Американским центром эффективности и качества (APQC), который продолжает поддерживать и развивать её. Текущая версия PCF - 6.1.0 от марта 2014 года.

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

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

Post-Implementation Review является неотъемлемой частью процесса управления изменениями в ITIL, служащим для оценки эффективности реализованных изменений и извлечения уроков. Он обеспечивает обратную связь в цикле улучшения услуг, позволяет определить соответствие результата поставленным целям и выявить области для дальнейшего совершенствования. Результаты PIR влияют на принятие решений по будущим изменениям, корректировку политик и процедур, а также на обучение команды.

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