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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

В документе Risk Scenarios Using COBIT 5 for Risk упоминаются четыре основные стратегии реагирования на риски: уклонение, принятие, передача и снижение. Для каждого сценария риска в документе указывается, какие из этих стратегий применимы. Кроме того, предлагается использование семи факторов влияния для реализации мер по снижению рисков, при этом для каждой меры приводится оценка её эффективности воздействия как на вероятность возникновения риска, так и на потенциальный ущерб в случае реализации риска.

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

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

Для учёта степени превышения срока обработки метрика может быть модифицирована за счёт добавления весового коэффициента wi, который учитывает, насколько сильно просрочен инцидент. Если инцидент решен в срок, wi=1. Если срок превышен, wi определяется как отношение фактического времени решения инцидента Ti к установленному сроку. Формула переписывается в виде: Кгруппы = (1/N) * Σ(wi * (1 - (ti/Ti) * vi)). Также можно ввести рейтинг ответственности ri = (ti/Ti) * vi. Тогда метрика принимает вид взвешенного арифметического среднего: Кгруппы = (1/N) * Σ(wi * (1 - ri)).

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

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

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