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

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

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

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

Для изучения путешествий применяют картографирование клиентских путей (customer journey mapping), наблюдение за реальными сценариями использования, глубинные интервью с акцентом на контекст и мотивы, анализ поведенческих данных (например, кликов в приложении), и составление persona-клиентов. Важно фиксировать не только точки взаимодействия, но и эмоциональные реакции, барьеры и неочевидные потребности. Также используют A/B-тестирование гипотез улучшений и сбор обратной связи через инструменты типа встроенных опросов в продукте. Ограничение таких техник в том, что они отражают лишь часть реального опыта, поэтому требуется постоянная итерация.

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

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

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

В контексте Service Improvement понятия Continual и Continuous имеют принципиальное различие. Continual Service Improvement (CSI) подразумевает непрерывный, но не обязательно постоянный процесс улучшения, происходящий через регулярные, периодические мероприятия, тогда как Continuous предполагал бы непрерывный безостановочный процесс. В русском языке этот нюанс сложно передать, но точнее будет говорить о «непрекращающемся» совершенствовании, так как улучшения происходят итеративно, в рамках регулярных циклов, а не постоянно без перерывов.

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