ABAC позволяет реализовывать гибкие и динамические правила доступа, учитывающие временные, географические и контекстные параметры (например, время суток, день недели, IP-адрес, стоимость заказа). Это даёт возможность более точного контроля доступа в сложных сценариях, таких как ограничение прав менеджера редактировать заказы только в своем филиале и только при стоимости ниже определённого порога. В отличие от RBAC, ABAC не привязан к жёстким ролям, что повышает адаптивность системы.

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

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

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

Контроль за задачами в статусе 'Ожидание' организуется через: регулярную (ежедневную или еженедельную) выгрузку списка всех задач в этом статусе; сегментацию списка по ответственным менеджерам и длительности нахождения в ожидании; автоматические уведомления ответственным за задачу при достижении установленного лимита времени ожидания; выборочную проверку причин перевода в статус с привлечением руководителей направлений; анализ статистики по категориям ожидания для выявления системных проблем (например, регулярные задержки поставок техники). Эффективный контроль включает не только проверку текущих задач, но и анализ причин частых переходов в статус 'Ожидание' для оптимизации процессов.

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

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

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

Структура описания фактора влияния в COBIT 5 включает набор универсальных атрибутов, которые одинаковы для любого фактора влияния, будь то процесс, услуга или информация. Эти атрибуты позволяют работать со всеми факторами влияния на единой, простой и структурированной основе, управлять комплексными взаимодействиями и обеспечивать успешные результаты их работы. В структуру входят: заинтересованные стороны, цели (с разделением на прямое и контекстуальное качество), хорошие практики и жизненный цикл процесса. Такой подход помогает систематизировать проектирование и развитие процессов, организовывать систему измерения и оценки эффективности.

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