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

Комбинирование RBAC и ABAC позволяет сохранить структурированность ролевой модели и добавить динамические условия проверки доступа. Например, роль «Менеджер» может быть дополнена правилом ABAC, ограничивающим редактирование заказов только при соблюдении условий: стоимость заказа не превышает 1000 руб., заказ находится в филиале менеджера. Это делает систему более гибкой, так как роли становятся контекстно-зависимыми, но при этом остаётся удобной для аудита благодаря явному разделению прав по ролям.

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

Стандарт INCITS 494-2012 делит ограничения на статические и динамические. Динамические ограничения включают: Роль-роль (запрет на одновременное использование ролей в одной сессии), Пользователь-роль (запрет пользователям исполнять данную пару ролей параллельно) и Атрибут (запрет на использование роли или прав доступа в зависимости от значения атрибута, такого как время суток, местоположение, цель использования и другие). Статические ограничения включают: Роль-роль (запрет на назначение роли конкретному пользователю), Пользователь-роль (запрет определённым пользователям быть назначенными на пару ролей), Права доступа-права доступа (запрет на комбинации прав доступа в роли) и Права доступа-роль (запрет на использование конкретных прав доступа в определенной роли).

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

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

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

При публикации статистических данных о внедрении ITIL часто искажаются аспекты, связанные с реальными показателями эффективности. Например, увеличение эффективности персонала на 80% или снижение количества инцидентов на 40% могут быть неподтвержденными цифрами. Искажению подвергаются также цели и функции отдельных процессов, что приводит к неправильному пониманию их роли и значимости.

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

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