Принцип "Действуйте итерационно" (Progress iteratively), описанный в ITIL Practitioner Guidance 2016 года, был дополнен в ITIL 4 2019 года до формулировки "Действуйте итерационно, используя обратную связь" (Progress iteratively with feedback). Это изменение подчеркивает важность не просто итерационного подхода к работе, но и обязательного сбора и учета обратной связи на каждой итерации. Авторы ITIL 4 таким образом делают акцент на том, что обратная связь является ключевым элементом успешных итераций, позволяющим корректировать дальнейшие шаги и улучшать результаты.

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

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

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

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

Автоматическая функциональная эскалация может корректно работать только в одном случае: если время обработки на уровне Ln истекло, и при этом этот уровень поддержки не только не решил инцидент, но даже не принял его в работу. Это работает как страховка от перегрузки конкретного уровня поддержки, позволяя автоматически привлечь следующий уровень (Ln+1). Однако такой сценарий предполагает, что специалисты обязательно сначала отмечают прием заявки в работу, а только потом фиксируют ее решение. На практике это условие часто нарушается, особенно в ситуациях с major-инцидентами, где множество заявок обрабатываются массово при закрытии общего инфраструктурного инцидента, не требуя индивидуального приема в работу каждым специалистом.

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

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

Запрос на получение информации о текущем статусе инцидента должен обрабатываться в процессе Управление инцидентами (Incident Management, INC). Этот процесс несёт ответственность за обеспечение прозрачности работы с инцидентами, включая коммуникацию информации о статусе инцидента. В ITIL Service Operation явно указано, что обеспечение прозрачности является частью задач процесса INC. В примере критических факторов успеха упомянут KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов», что подразумевает необходимость минимизации таких запросов за счёт качественной коммуникации в рамках INC. Хотя процесс Управления запросами на обслуживание (Request Fulfillment Management, RFF) может использоваться как канал передачи информации, основная ответственность за организацию коммуникации и прозрачность лежит на INC, поэтому именно этот процесс должен отрабатывать запросы о статусе инцидента.

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