Архитектурные решения критически важны, потому что сложные, монолитные системы, созданные годами и состоящие из тесно связанных компонентов, просто не могут поддерживать высокую скорость разработки. Такие системы, где аббревиатура 'CI/CD' вызывает удивление или смех, принципиально не позволяют достигнуть кратного ускорения. Чтобы достичь значительного снижения Time to Market, необходимо провести работу над архитектурой: разбить монолит на микросервисы или модули, внедрить автоматизацию тестирования и развертывания, создать условия для параллельной работы нескольких команд без постоянных конфликтов. Эти изменения требуют значительных усилий и инвестиций, но без них реальное кратное ускорение невозможно.

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

Роли менеджера изменений в ITIL часто вызывают неоднозначность, потому что в ITIL V3 эта роль не была описана как отдельная, а вместо нее упоминались другие роли, такие как владелец процесса и практик. В зависимости от контекста и организации роль 'менеджера изменений' могла включать в себя различные функции, иногда совмещая обязанности менеджера процесса, администратора изменений и председателя CAB. Даже в ITIL4, где роль менеджера изменений стала официальной, остается гибкость в распределении обязанностей: менеджер изменений может выступать как универсальный ролевой игрок, объединяющий несколько функций, или его обязанности могут быть распределены между менеджером изменений и координаторами, в зависимости от масштаба организации и сложности изменений.

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

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

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

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

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

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

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