Затраты на ИТ-персонал составляют 40-60% операционных затрат, что делает их одной из самых значительных статей расходов. Учитывая, что операционные затраты в среднем составляют около 75% от общего бюджета ИТ, доля затрат на персонал в итоге достигает 30-45% всего ИТ-бюджета, что делает её критически важной для оптимизации.

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

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

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

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

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

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

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

Помимо ролевой модели управления доступом (RBAC), существуют альтернативные и дополнительные подходы, которые могут использоваться отдельно или в комбинации с RBAC. Это включает в себя управление доступом на основе атрибутов пользователей (ABAC), где решения о предоставлении доступа принимаются на основе различных атрибутов (роль, должность, отдел, время суток и т.д.). Также применяются динамические правила предоставления доступа, когда права назначаются временно в ответ на конкретные запросы. Еще одним подходом являются запросы прав доступа, когда пользователь сам инициирует запрос на получение определенных прав, который затем проходит процесс утверждения. Кроме того, существует модель управления доступом на основе риска, где уровень предоставленных прав зависит от оценки риска. Эти подходы часто комбинируются с RBAC для создания более гибких и адаптивных систем управления доступом, учитывающих сложность современных бизнес-процессов.

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