При настройке визуализации в CMDB учитываются различные категории конфигурационных единиц (CI): для лицензий отображаются одни типы связей, для серверов и программного обеспечения — другие, а для документов — третьи типы связей. Это позволяет адаптировать представление данных в зависимости от специфики конкретной конфигурационной единицы и повышает информативность диаграмм.

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

В процессе непрерывного улучшения услуг (CSI - Continual Service Improvement) BRM играет важную инновационную роль. BRM определяет возможности по оптимизации ценности, которую сервис-провайдер несет заказчикам. BRM может выявлять возможности как в рамках текущей деятельности (благодаря постоянной осведомленности о задачах заказчика), так и в рамках периодических service reviews. BRM отвечает за документирование выявленных возможностей или потребностей и их передачу для дальнейшей проработки. BRM также отслеживает прогресс реализации улучшений и при необходимости выступает координатором деятельности, выполняемой в рамках других процессов, особенно в случаях риска потери фокуса на цели улучшения.

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

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

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

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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

Для управления сложными изменениями с несколькими координаторами рекомендуется создать централизованную группу управления изменениями (Change Advisory Board), которая будет координировать работу всех участников процесса. Необходимо четко определить роли и ответственность каждого координатора, наладить коммуникацию между командами и использовать инструменты автоматизации для отслеживания статуса изменений. Также важно разработать протоколы согласования изменений и внедрить этапы тестирования и обратной связи перед реализацией.