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

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

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

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

Да, целевые показатели доступности могут быть временно скорректированы на период внедрения безотлагательных изменений. Это возможно при условии, что необходимость такой корректировки действительно обоснована и все заинтересованные стороны согласны с её проведением. Процесс управления уровнем услуг (Service Level Management) отвечает за обсуждение и согласование таких изменений в целевых показателях с заказчиком, обеспечивая прозрачность и управляемость процесса. Важно, чтобы такие временные корректировки не становились регулярной практикой и не снижали в долгосрочной перспективе общее качество предоставляемых услуг.

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

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

Международная ассоциация менеджеров по управлению ИТ-активами (IAITAM) проводит анализ лицензионных соглашений, фиксируя распространенные условия и рекомендации в своей библиотеке IBPL. Также стандарт ISO 19770 регламентирует подходы к управлению активами ПО и включает рекомендации по соответствию лицензионным соглашениям.

Для определения ПО, требующего лицензирования, необходимо составить список критически важных программ (например, Microsoft Suite, Adobe Photoshop), проанализировать правила лицензирования вендоров (особенно сложные, как у Oracle), и использовать сканеры сети для выявления фактически установленных продуктов. Затем данные следует сопоставить с купленными лицензиями. Важно сосредоточиться на тех продуктах, где наиболее высок риск нарушения лицензионных соглашений или штрафов (например, часто копируемый софт). Серверное ПО обычно менее приоритетно для первоначального учёта.

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