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

Организация работы через веб-клиент позволяет сотрудникам работать с системой через любой браузер, что обеспечивает полный функционал без ограничений, характерных для почтового клиента. Однако этот метод требует стабильного онлайн-соединения с сервером на протяжении всего сеанса работы и предъявляет определенные требования к браузеру (поддержка CSS, JavaScript, AJAX и других современных технологий), что может создавать сложности при использовании на устаревшем оборудовании или в условиях плохого интернет-соединения.

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

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

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

Отчет выделил три основных сценария: 1) Выживание предприятия преимущественно за счет реструктуризации и частичного сокращения бизнес-направлений; 2) Пережидание кризисного периода за счет эффективности, без существенного сокращения бизнес-направлений; 3) Активное расширение бизнеса, выход новых продуктов и услуг, экспансия на новые рынки.

Структура IT4IT первого уровня (Level 1) представлена через призму потоков создания ценности (Value Streams), где все элементы модели выстроены вокруг сервисной модели (Service Backbone) как основы. Это создает более явную и структурированную картину того, как различный ИТ-активы взаимодействуют для создания ценности. В ITIL v3 структура основана на жизненном цикле услуги (Service Lifecycle), представленном как последовательность фаз: стратегия, дизайн, переход к эксплуатации, эксплуатация и непрерывное улучшение. В то время как ITIL v3 фокусируется на том, что происходит с услугей на разных этапах ее жизни, IT4IT Level 1 делает акцент на том, как потоки работы проходят через организацию для создания этой услуги. IT4IT Level 1 предоставляет более явные связи между бизнес-потребностями и ИТ-реализацией через Value Streams, тогда как ITIL v3 предоставляет более детализированный взгляд на управление самой услугой на разных этапах ее жизненного цикла.

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

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

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