FTR (First Time Resolution) — это показатель, представляющий долю инцидентов, решенных с первого раза без необходимости переделок или доработок. Снижение FTR негативно влияет на процесс управления инцидентами,因为它 указывает на то, что решения не проходят достаточной проверки или не полностью устраняют проблему, что приводит к необходимости повторного рассмотрения инцидентов. Это увеличивает нагрузку на службу поддержки, снижает рациональность процесса, ухудшает показатели эффективности и может негативно сказываться на удовлетворенности клиентов.

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

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

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

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

Incident Rate выражается на одного пользователя, поэтому показатель уменьшает влияние масштаба компании на оценку количества инцидентов. Это позволяет сравнивать разные организации независимо от их размера, а также оценивать динамику изменений внутри одной компании. Общее количество инцидентов варьируется гораздо шире (например, от десятков до тысяч в день) и не учитывает размер организации, что затрудняет использование в прогнозировании и сравнении.

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

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

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

Более важным при внедрении процессов является формирование культуры измерения и понимания её ценности среди сотрудников, нежели формальное заполнение раздела KPI. Разработка метрик без понимания их цели и применения приведет к созданию формальных показателей, которые не будут использоваться для принятия реальных решений.