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

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

Функциональная эскалация инцидентов — это процесс передачи заявки от одного уровня поддержки к следующему по иерархии (например, с L1 на L2 или с L2 на L3) при необходимости более глубокой диагностики или решения сложной проблемы. Она отличается от временной эскалации, которая связана с нарушением сроков SLA и требует вмешательства менеджмента, и от персональной эскалации, когда заявка передается конкретному специалисту или руководителю по содержательным вопросам. Функциональная эскалация определяется сложностью проблемы и необходимостью привлечения специалистов с более высоким уровнем компетенции, тогда как другие виды эскалации могут быть связаны с организационными или временными аспектами обработки заявок.

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

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

Рекомендуется изучать ITIL через призму практических примеров, фокусироваться на том, как концепции работают в реальности, а не на дословном освоении терминов. Также полезно обсуждать сложные моменты с коллегами, искать альтернативные объяснения и помнить, что управление ИТ-услугами в жизни проще и логичнее, чем в теоретических материалах.

ITIL выделяет три типа поставщиков услуг: Тип I и Тип II (внутренние поставщики) и Тип III (внешние поставщики). Для внутренних поставщиков (Тип I и Тип II) финансовые штрафы обычно отсутствуют, а ответственность выражается в виде уменьшения премий сотрудников ИТ-подразделения. Штрафы могут применяться автоматически или на усмотрение руководства, что делает применение санкций менее однозначным. Для внешних поставщиков (Тип III) предусматриваются реальные финансовые санкции, но их размер и применение часто ограничены. Например, сумма штрафов обычно не превышает 20–30% от суммы контракта, а в некоторых законах, таких как 44-ФЗ, штрафные санкции определены значительно ниже, в диапазоне от 0,5% до 2,5% от суммы контракта.

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

Команда на уровне «Зрелость» представляет собой агента изменений на уровне всей компании. Она полностью контролирует свой рабочий процесс и несет ответственность за продукт на уровне P&L (прибыль и убытки), что означает управление финансовой стороной продукта. Инициативы направляются не только внутрь команды, но и наружу, команда стремится расширять зону влияния и инициирует изменения, затрагивающие множество служб и подразделений компании. Для такой команды лидер-слуга уже не нужен, как и лидер-наставник. Здесь требуется лидер-партнер с достаточными полномочиями для поддержки командных инициатив на высшем уровне, обладающий широкой осведомленностью о направлении развития компании и достаточным авторитетом для интеграции целей команды с целями компании. Это высшая ступень развития, где команда становится драйвером изменений в организации.

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