Сервисно-ресурсная модель (СРМ) — это концепция, применяемая в управлении активами и конфигурациями, которая фокусируется на взаимосвязях между сервисами и ресурсами в организации. Она предполагает детальное описание всех компонентов системы, их отношений и роли в обеспечении конечных сервисов. Эта модель служит основой для управления изменениями, анализа воздействия и планирования инцидентов.

EULA (End User License Agreement) - это лицензионное соглашение с конечным пользователем, которое определяет условия использования программного обеспечения. Оно включает в себя не только информацию о количестве лицензий, но и множество других условий и ограничений, таких как запреты на установку ПО на сервера, использование в коммерческих целях и другие правила, соблюдение которых критично для соответствия требованиям.

Для управления рисками в области IT существуют различные методы и стандарты, такие как CRAMM, COSO ERM, ISO 27005, OCTAVE и MEHARI. Все эти методики описывают известный цикл управления рисками, состоящий из этапов: определение охвата, идентификация, анализ, оценка, реагирование и контроль. Этот цикл официально закреплен в стандарте ISO 31000 с 2009 года. Каждая методика предлагает свой подход к формулированию рисков. Например, ITSM-специалисты часто используют модель «актив-угроза-уязвимость», в то время как PMBOK рекомендует структуру «причина-событие-последствие». ISACA в своих публикациях, начиная с RiskIT и в частности в COBIT 5 for Risk, предлагает концепцию сценария риска, включающего источник угрозы, тип угрозы, событие, связанные активы и временной аспект.

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

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

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

При отсутствии ранее существовавшей документации по управлению активами и конфигурациями рекомендуется использовать название "План управления сервисными активами и конфигурациями" (SACM plan). Это соответствует рекомендациям ITIL v3 2011 (раздел Service Transition, 4.3.5.2). При необходимости, учитывая специфику организации, название может быть адаптировано к таким вариантам как "Положение" или "Регламент". Ключевой момент - документ должен описывать целевой уровень управления сервисными активами и конфигурациями, который организация определяет самостоятельно. Структура документа должна включать разделы по охвату, требованиям, политикам и стандартам, организационной структуре, описанию процедур и связям с другими процессами.

Концепция сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (внутренний или внешний), тип угрозы (злоумышленные действия, ошибки, природные катастрофизмы и т.д.), событие (раскрытие информации, модификация, кража, уничтожение и т.д.), связанные активы (люди, оргструктуры, процессы, ИТ-инфраструктура и т.д.) и временной аспект, учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от календарного периода или времени суток. COBIT 5 for Risk также предоставляет более ста различных сценариев рисков, разделенных на 20 категорий, от управления ИТ-инвестициями до рисков, связанных с поставщиками и атаками, с рекомендациями по снижению рисков, сгруппированными по семи факторам влияния.

Система Управления Конфигурациями (Configuration Management System, CMS) определяется как набор инструментов, данных и информации, которые используются для поддержки процесса управления сервисными активами и конфигурациями. CMS является частью общей системы управления знаниями по услугам и включает в себя инструменты для сбора, хранения, управления, обновления, анализа и представления информации обо всех конфигурационных единицах и их взаимоотношениях. CMS может также содержать информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Кроме того, CMS поддерживается процессом управления сервисными активами и конфигурациями и используется всеми процессами управления ИТ-услугами.

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