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

Комбинирование RBAC и ABAC позволяет достичь значительного сокращения количества необходимых правил или ролей, сохраняя при этом гибкость системы. Например, в системе с 10 атрибутами (7 статическими и 3 динамическими) классическая ролевая модель потребовала бы 2^10 (1024) ролей, тогда как комбинированная модель требует всего 2^7 (128) ролей и 2^3 (8) атрибутных правил. Это существенное упрощение, так как большинство атрибутов в реальных системах (должность, подразделение и т.д.) являются статическими и редко меняются, а динамические атрибуты (например, время суток) требуют гораздо меньшего количества правил.

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

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

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

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

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

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

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

Для объединения двух tension-метрик в один общий KPI необходимо использовать геометрическое среднее (а не арифметическое). Если K1 — метрика своевременности, а K2 — метрика результативности, то итоговый K = √(K1 × K2). Это обеспечивает чувствительность к игнорированию одной из метрик (при значении одной из них в 0% общий KPI также будет равен 0%), в то время как при равных значениях обеих метрик итоговый KPI соответствует уровню их значений. Геометрическое среднее лучше отражает баланс между метриками, чем арифметическое, поскольку низкое значение одной метрики сильно влияет на общий результат.