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

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

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

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

В 2010 году в магическом квадрате Гартнера по ITSM-продуктам свои позиции потеряли такие компании, как HP, CA и IBM, которые переместились из категории лидеров в категории претендентов или нишевых игроков. При этом BMC Remedy ITSM Suite осталась единственным лидером. Изменения позиций произошли преимущественно из-за переоценки маркетинговой активности, стратегического видения и способности поддержки долгосрочных партнерских отношений, нежели из-за фундаментальных изменений в продуктах.

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

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

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

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

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