Метрика First Time Resolution (FTR) в разрезе рабочих групп рассчитывается по формуле: FTR = (Nj - Sj) / Nj. Здесь Nj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций (Cj), плюс количество возвратов на доработку в эту группу (Sj). Sj — это количество объектов, возвращенных на доработку в j-тую группу. Расчёт производится за период, когда завершена процедура проверки решения инцидента, а не фактическое решение задачи. Важно учитывать возвраты индивидуально по каждой группе, так как одно обращение может быть переназначено в другую группу или возвращено несколько раз в разные группы.

Ключевые индикаторы успешного аутсорсинга: 1. Наличие коммерчески ориентированного руководителя, а не ИТ-директора из материнской компании. 2. Система оплаты руководителя, где отсутствие успехов на открытом рынке приводит к снижению зарплаты ниже рыночной, а успешная коммерческая деятельность обеспечивает значительный доход. 3. Аутсорсинг услуг, имеющих альтернативный спрос и предложение на рынке. 4. Наличие четкого бизнес-плана с перспективами коммерческой деятельности на открытом рынке. 5. Разрешение на извлечение прибыли при оказании услуг материнской компании без чрезмерного влияния на доходы руководства аутсорсера.

Формула расчёта First Line Resolution (FLR): R/N, где R — количество обращений, решённых на первой линии поддержки, N — общее количество обращений, поступивших на первую линию за отчётный период. Формула расчёта First Contact Resolution (FCR): C/N, где C — количество обращений, решённых в ходе первичного контакта с пользователем, N — общее количество обращений, поступивших в заданную группу за отчётный период. Обе метрики измеряют долю успешно разрешённых обращений к общему количеству поступивших обращений, но с разными критериями успешного разрешения.

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

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

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

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

В усовершенствованной метрике продуктивности управления проблемами коды закрытия делятся на три категории: а) проблема решена – обработка принесла пользу, ресурсы использованы эффективно; б) проблема закрыта без решения, но с непродуктивной тратой ресурсов – есть вред от напрасной работы; в) проблема закрыта без решения, но без вреда и пользы – например, дубли, закрытые на этапе первичной оценки. Каждая группа учитывается в формуле метрики по-разному для повышения её точности.

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

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