Для определения данных, подлежащих переносу в CMDB, используются следующие критерии: 1) Удобство использования - данные должны быть доступны в интерфейсе CMDB без перехода в другие системы; 2) Необходимость поиска - если требуется выполнять поиск или группировку конфигурационных элементов (КЕ) по определенному атрибуту, этот атрибут должен находиться в самой CMDB; 3) Потребность в отчетности - если для формирования отчетов по КЕ требуются атрибуты из внешних систем, необходимо либо перенести эти атрибуты в CMDB, либо создать консолидированный источник данных для отчетов.

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

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

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

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

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

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

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

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

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