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

Сервисно-ресурсная модель помогает определить затраты на предоставление ИТ-услуги, распределяя их по различным компонентам, включая виртуальные серверы. Хотя такая модель может приписать конкретные затраты каждому элементу, это не автоматически делает эти элементы ИТ-активами. Модель показывает экономическое обоснование затрат, но не определяет, является ли элемент объектом собственности организации. Сервисно-ресурсная модель полезна для понимания экономики предоставления услуг, но для классификации элементов как ИТ-активов требуется дополнительный критерий финансовой ценности и собственности.

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

Для успешного внедрения конвейера развёртывания необходимо соблюдение нескольких ключевых условий. В области работы с исходным кодом требуется дисциплинированный подход к управлению версиями — использование современных стратегий ветвления Git с минимальным количеством долгоживущих веток и отсутствием зависимости от одного человека для выполнения мержей. Также требуется развитая культура автоматизированного тестирования: команда должна понимать важность написания и постоянного обновления автотестов, а не проводить дебаты о том, нужны ли они вообще. Кроме того, необходим переход от редких релизов (раз в месяц или квартал) к более частым, для чего также нужно изменить ожидания заказчиков. Эти условия являются минимальной базой, и отклонение от них создаст серьезные препятствия для построения эффективного CI/CD конвейера.

План коммуникаций для проекта включает несколько важных компонентов: определение заинтересованных сторон (стейкхолдеров), выяснение какая информация в какой форме, объеме, формате и с какой периодичностью нужна каждому стейкхолдеру, установление способов обратной связи, выбор типов коммуникаций (электронная почта, встречи, собрания, меморандумы и т.д.), учет возможных факторов, ведущих к конфликтам или недопониманию, а также разработку способов их решения. Согласно ITIL Practitioner, план коммуникаций должен отвечать на вопросы: кто и какую информацию должен получать, какова цель этой информации, какие форматы и средства передачи информации наиболее эффективны, кто и когда должен направлять информацию, как проверить её правильное понимание, и какой обратной связи необходимо добиться. План коммуникаций — это документ, который регулярно анализируется и совершенствуется на протяжении всего проекта.

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

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

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

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

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