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

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

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

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

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

Даже при затрудненном точном расчете Flow Efficiency оценка этого показателя имеет большую практическую ценность, поскольку помогает командам осознать реальный уровень эффективности своих процессов. Чаще всего команды субъективно оценивают свою эффективность как 75-80%, в то время как объективная оценка (даже приблизительная) показывает значения в 10-25%. Это позволяет выявить основные источники потерь времени и сосредоточиться на их устранении. Такая оценка служит мощным инструментом для инициирования обсуждений и поиска путей улучшения процессов, даже без точных численных данных. Таким образом, основная ценность Flow Efficiency заключается не в цифре как таковой, а в прозрении, которое она дает команде относительно своих процессов.

Важно устанавливать четкие временные рамки для CI/CD конвейера, чтобы избежать неопределенных ситуаций и иметь объективный критерий эффективности работы. Например, если установлено, что конвейер должен доставлять изменения до продуктивной среды не дольше чем за 15 минут, это создает четкий ориентир для оценки его работы. Такая конкретика не оставляет места для расплывчатых формулировок вроде 'как бы работает, но не очень' или 'вчера был, сегодня нет'. Четкие временные рамки помогают команде понимать, соответствует ли система требованиям и когда требуется вмешательство. Это также способствует дисциплине и ответственности внутри команды, так как все понимают, что конвейер должен работать стабильно и быстро, без компромиссов.

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

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

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