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

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

Существует четыре основные причины применения измерений в бизнесе: 1) подтверждение того, что ранее принятые решения остаются актуальными; 2) направление деятельности на достижение требуемых целей; 3) обоснование необходимости предполагаемых действий; 4) возможность вмешательства в ход деятельности для её корректировки. Эти принципы позволяют использовать измерения как инструмент управления бизнес-процессами.

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

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

Автоматизация в управлении изменениями может быть реализована через интеграцию с конвейерами непрерывной интеграции и доставки (CI/CD). Если организация использует CI/CD, модель изменения должна учитывать эти процессы, чтобы автоматизировать этапы тестирования, развертывания и мониторинга. Это позволяет сократить время внедрения и повысить качество изменений за счёт предсказуемости и отсутствия ручных ошибок. Автоматизация особенно эффективна для регулярных, структурированных изменений.

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

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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.