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

Анализ затрат включает план-фактный анализ, сравнение однотипных подразделений между собой (например, на разных территориях), изучение косвенных неотнесенных затрат, сравнение с рынком и формирование инициатив по оптимизации затрат. Это ключевой элемент поиска возможностей для снижения расходов.

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

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

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

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

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

Потери бизнеса вследствие простоев ИТ-услуг определяются тремя основными факторами: 1) Общим временем простоя за период - чем больше суммарное время недоступности, тем больше потери; 2) Продолжительностью отдельных простоев - для многих бизнес-процессов критичны не просто суммарные потери времени, а именно длительные непрерывные простои, которые могут привести к экспоненциальному росту ущерба (штрафы, утрата клиентов, репутационные потери); 3) Частотой прерываний - некоторые бизнес-процессы особенно чувствительны к частым кратковременным простоев (например, системы, требующие длительных вычислений, которые необходимо перезапускать после каждого простоя).

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

Содержание (utility) и условия предоставления (warranty) ИТ-услуг в сложных сервисных отношениях определяются множеством факторов, включая требования различных заказчиков, разделение функций заказчика и плательщика, организационную структуру компании и сложность внутренних взаимодействий. В условиях Value network, где может быть несколько заказчиков для одной услуги и разделение заказчика и плательщика, решение о содержании услуги должно учитывать разные точки зрения и интересы, сбалансировать противоречивые требования. Условия предоставления определяются не только техническими возможностями ИТ-подразделения, но и договорными отношениями с заказчиками, способом аллокации затрат и наличием механизма возмещения стоимости. Для определения четких параметров utility и warranty необходимо четкое определение зон ответственности, создание прозрачной аллокационной модели и в некоторых случаях трансформация организационной структуры и системы отчетности.