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

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

Ключевые переменные, влияющие на баланс между Agile (гибкостью) и стабильностью в ИТ: Release rate (частота внедрений) и Release size (средний размер внедрения). Чем выше частота внедрений (Release rate), тем меньшими порциями можно внедрять изменения (меньше Release size), и наоборот. Частые внедрения помогают сокращать размер очереди изменений (Backlog Size), уменьшают риски (Change Risk) и способствуют накоплению опыта. Большой размер релиза приводит к повышенным рискам, поскольку сложнее планировать и контролировать изменения. Также важны Process Time (время работы над изменением), Queue Time (время ожидания в очереди), Change capability (способность ИТ-организации проводить изменения) и Change Control Level (уровень контроля изменений), которые определяют эффективность и качество процесса внедрения изменений в систему.

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

В издании ITIL 4 2019 года («ITIL Foundation: ITIL 4 Edition») было семь руководящих принципов, тогда как в предыдущей версии, описанной в книге «ITIL Practitioner Guidance» 2016 года, их было девять. Количество принципов было уменьшено с девяти до семи, при этом основная идея системы принципов сохранилась. Некоторые принципы из предыдущей версии были объединены, а часть формулировок изменена незначительно. Таким образом, все идеи из девяти принципов 2016 года нашли отражение в семи принципах ITIL 4 2019 года, но система стала более компактной, сохранив при этом практичность и полноту.

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

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

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

Для определения необходимости и достаточности набора метрик необходимо использовать методологию, которая включает установление назначения процесса и разработку метрик соответствия этому назначению, установление ключевых практик и разработку метрик для этих практик. Дополнительно можно применять Causal Loop Diagram (CLD), который связывает ключевые факторы системы управления и отражает их взаимное влияние. Анализируя элементы CLD и соотнося их с предлагаемыми метриками, можно проверить полноту и адекватность набора метрик, а также определить, покрывают ли они все аспекты управления процессом.

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