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

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

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

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

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

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

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

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

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

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