Уровень System Capacity Management определяется как управление мощностью на уровне информационных систем. Этот подпроцесс используется, когда ИТ-услуга ассоциируется с обеспечением работоспособности конкретных систем. Он включает в себя определение требований к производительности, надежности и доступности систем, а также трансляцию этих требований в ресурсные ограничения. System Capacity Management необходим при предоставлении услуг, ориентированных на систему (например, SaaS), но не требуется, если услуга определена напрямую как предоставление ресурсов.

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

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

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

Предложенная метрика решает проблему сложности установки целевых значений за счет своей нормированности - она всегда находится в диапазоне от 0 до 1. Это позволяет легко определить целевые значения (например, 80-90%) без сложных расчетов, зависящих от объема работы. При этом существует два варианта методики установки целевого значения: ориентация на соотношение длительности отчетного периода к среднему времени решения проблем, или фиксация целевого уровня (например, 80-90%), при условии выбора отчетного периода, равного или немного большего среднего времени решения проблемы. Это делает цели измеримыми и достижимыми.

В контексте цифровой трансформации эффект Даннинга-Крюгера проявляется в том, что многие организации и специалисты неадекватно оценивают свои возможности и знания в новых технологических областях. Это может приводить к излишней самоуверенности в устаревших методах (например, ручное тестирование вместо CI/CD) или, наоборот, к неуверенности в необходимости внедрения новых практик (ежедневные релизы). Как указано в тексте, успешная цифровая трансформация требует не только технических изменений, но и работы с персоналом – повышения уровня компетенции, обучения адекватной самооценке и формирования правильной мотивации.

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

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

Выбор модели зависит от требований к гибкости, сложности системы и необходимости аудита. Например, в простых системах с чёткими ролями достаточно RBAC, тогда как в динамичных средах (многофилиальные компании) гибридная модель с ABAC обеспечит точный контроль. Неверный выбор может привести к избыточной сложности (чистый ABAC) или недостаточной адаптивности (только RBAC).

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