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

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

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

FTA можно интегрировать в процессы ITIL следующим образом: в рамках Service Design метод помогает выявить потенциальные отказы при проектировании системы, определять требования к компонентам на основе показателей гарантии и отсеивать заведомо ненадежные архитектурные решения; для управления непрерывностью ИТ-услуг (ITSCM) FTA позволяет понять, какие комбинации событий приведут к нарушению доступности критичной функциональности, и подготовиться к ним, определив меры предотвращения или пути быстрого восстановления. При этом анализ помогает установить точные зависимости между сбоями конфигурационных единиц (КЕ) и отказом функциональности, что упрощает расчет целевых показателей восстановления (RTO, RPO) для конкретных КЕ.

Да, в открытых источниках есть данные за 2012 и 2018 годы, которые демонстрируют различия по отраслям. В 2012 году разрыв между отраслями был значительным: в финансовом секторе — до 4–5 обращений на пользователя в месяц, в здравоохранении — около 0,8–1. К 2018 году разрыв сократился: лидеры снизили нагрузку (до 2,5–3). Это связано с ростом ИТ-грамотности пользователей и улучшением качества услуг. В 2020 году из-за пандемии наблюдался кратковременный рост обращений на 16% из-за массового перехода на удалёнку.

Основные недостатки ABAC связаны со сложностью управления и аудита. Из-за использования множества атрибутов и условий правила становятся запутанными, требуют постоянного обновления и сложны в поддержке. В отличие от RBAC, где права явно привязаны к ролям, в ABAC невозможно быстро определить, какие именно привилегии имеет конкретный пользователь, так как модель не оперирует понятием «права». Это делает ABAC неэффективным для аудита и управления правами на уровне отдельных пользователей.

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

WIP-лимиты (Work in Progress Limits) оказывают значительное влияние на сокращение Time to Market, ограничивая количество задач, одновременно находящихся в работе. Это предотвращает перегрузку команды, уменьшает контекстные переключения и позволяет сосредоточиться на завершении текущих задач вместо их бесконечного запуска. Когда команда не пытается сделать всё сразу, но фокусируется на ограниченном количестве задач, циклическое время каждой задачи существенно сокращается. Например, в деловой игре 'Проект Феникс' внедрение WIP-лимитов и упорядочение потока работы позволили снизить Time to Market с 25 минут до 40 секунд - 1,5 минуты. WIP-лимиты также делают проблемы видимыми, так как перегрузка и узкие места становятся очевидными, что позволяет оперативно их устранять.

В состав Nj при расчёте FTR должны входить только те обращения, обработанные j-той группой, по которым процедура проверки решения полностью завершена. К ним относятся: закрытые без рекламаций инциденты (Cj) и возвраты на доработку (Sj). Не включаются в Nj обращения, которые всё ещё находятся в процессе обработки или где проверка решения не завершена, так как они не могут быть учтены при определении качества работы группы.

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