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

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

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

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

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

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

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

BRM участвует на всех основных этапах жизненного цикла услуги согласно ITIL. На этапе Service Strategy BRM держит руку на пульсе бизнеса заказчика, знает его задачи и изменения в деятельности, помогает коммуницировать стратегические цели заказчика ИТ-специалистам. На этапе Service Design BRM помогает сформулировать ценность услуги для заказчика и правильно расшифровать требования ИТ-специалистам. На этапе Service Transition BRM обеспечивает вовлечение заказчика в тестирование и передачу/приемку услуги. На этапе Service Operation BRM следит за тем, чтобы заказчик получал ожидаемую ценность и удовлетворенность, управляя процессом обработки жалоб. На этапе CSI (Continual Service Improvement) BRM определяет возможности по оптимизации услуги и участвует в service reviews для постоянного улучшения предоставляемых сервисов.

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

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