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

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

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

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

Игра Grab@Pizza считается полезной для профессионального развития, поскольку она предоставляет участникам возможность в игровой форме проработать реальные бизнес-ситуации и понять сложности взаимодействия между бизнесом и ИТ. Участники могут демонстрировать свои навыки и способности в решении кризисных ситуаций, что позволяет руководителям оценить их потенциал для дальнейшего карьерного роста. Игра также помогает развить понимание процессов ITSM, научиться эффективно взаимодействовать с коллегами из разных отделов и понять, как правильно обосновывать и приоритезировать ИТ-инициативы с точки зрения бизнеса.

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

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

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

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

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