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

В процессе управления релизами ITIL V3 выделены следующие технические роли: Практик пакетирования и построения релизов, занимающийся сборкой и подготовкой компонентов релиза; Практик развёртывания релизов, отвечающий за внедрение релиза в производственную среду и подготовку документации; Практик первичной (early life) поддержки, обеспечивающий поддержку системы в начальный период эксплуатации после релиза. Эти роли сосредоточены на выполнении конкретных работ, а не на координации процесса в целом. Все они работают под управлением менеджера процесса и обеспечивают техническую реализацию отдельных этапов жизненного цикла релиза.

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

На уровне отдельного приложения роли определяются как наборы прав на конкретные объекты и операции (системные роли, например, 'Редактор контента'). Для масштабирования до предприятия: 1) Системные роли группируются в бизнес-роли, отражающие функции сотрудников (например, 'HR-специалист' включает роли в ATS, HRM и системе обучения). 2) Вводится иерархия бизнес-ролей по подразделениям (например, 'HR-специалист' может быть 'Рекрутером' или 'Тренером'). 3) Устанавливаются связи между бизнес-ролями и организационной структурой (каждое подразделение имеет свой набор ролей). На предприятии управление сводится к назначению бизнес-ролей пользователям, а системные роли обновляются автоматически при изменениях в приложениях.

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

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

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

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

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

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