Управление проблемами часто недооценивается бизнесом потому, что его ценность недостаточно осязаема и количественно не видна на начальном этапе. Эта деятельность происходит 'под капотом' ИТ-инфраструктуры и не имеет прямых, мгновенно измеряемых результатов. Бизнес видит только результаты управления инцидентами (восстановленные сервисы), но не видит предотвращенных инцидентов благодаря управлению проблемами. Для обоснования инвестиций требуется демонстрация количественной отдачи и объяснение долгосрочных преимуществ в уменьшении инцидентов и экономии ресурсов.

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

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

Метрика естественным образом масштабируется: если представить ситуацию, когда группа поддержки представляет собой весь персонал поставщика услуги (то есть единственная группа), то время обработки группой (ti) становится равным общему времени обработки инцидента (Ti). В этом случае формула упрощается до вида: Кгруппы = (1/N) * Σ(1-vi), то есть представляет собой привычную метрику «доля инцидентов, решённых в срок». Таким образом, метрика применима как к отдельным группам, так и к оценке эффективности всего процесса управления инцидентами в целом.

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

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

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

В расширенной RASCI-матрице символ S означает Supports (Поддерживающий) - это участник, который участвует в исполнении задачи, но не отвечает за ее организацию или конечный результат. Для сотрудников, находящихся в позиции S, рекомендуется делегировать непосредственное исполнение задачи другим сотрудникам, сохранив за собой роли контролирующего (I - Informed) или консультирующего (C - Consulted). Это позволяет избежать ситуации, когда подчиненные выполняют работу под чужим руководством, что может привести к отсутствию контроля со стороны непосредственного руководителя. Сохранение позиции в информационном потоке (I или C) обеспечивает руководителю возможность контролировать процесс и вносить корректировки при необходимости, не отнимая времени на прямое исполнение задачи.

После выявления «известной ошибки» она документируется в специальной базе данных известных ошибок (KEDB - Known Error Database). В запись об ошибке включается информация о корневой причине, описании проблемы, временном обходном решении (workaround), а также данные о влиянии на бизнес и истории связанных с ней инцидентов. Эта информация используется при возникновении аналогичных инцидентов для быстрого применения известного обходного решения. Запись поддерживается в актуальном состоянии и обновляется по мере получения новых данных или поиска постоянного решения проблемы.

Если в процессе не используется понятие 'переоткрытый инцидент', показатель First Time Resolution (FTR) можно получить, анализируя долю инцидентов, с которыми связаны более поздние инциденты, при условии, что система автоматизации процесса управления инцидентами позволяет связывать инциденты друг с другом. Если связь инцидентов используется и для других целей, анализ может стать несколько сложнее, но остается возможным. Также можно формировать полную систему оценки, в которой FTR не учитывается отдельно, поскольку переоткрытые инциденты влияют на другие показатели, например TCR (Ticket Closure Rate).