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

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

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

В ITIL V3 2011 роль менеджера изменений не была отдельно описана - вместо нее существовали роли владельца процесса, менеджера процесса, инициатора, практика, авторизующего и участника CAB. В ITIL4 роль менеджера изменений (Change manager) стала официальной в рамках практики 'Поддержка изменений' (Change enablement) как специфическая роль, включающая управление жизненным циклом отдельных изменений и развитие самой практики. В ITIL4 также появилась дополнительная роль координатора изменений (Change coordinator) для работы в ограниченном контексте, в то время как владелец практики отвечает за общее управление практикой.

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

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

При прямом измерении удовлетворённости заказчика учитываются как warranty (гарантийные аспекты, связанные с надежностью, доступностью и безопасностью услуг), так и utility (полезность услуги, соответствие потребностям и функциональным требованиям). Такой подход позволяет оценить не только количественные показатели, прописанные в SLA, но и общее впечатление заказчика об услуге, а также соответствие реальных результатов его ожиданиям и бизнес-потребностям.

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

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

Добавление критериев завершения (Definition of Done) в визуализацию процесса важно потому что в вытягивающей системе (Pull System) каждый следующий шаг в потоке сам забирает задачи. Чтобы система работала правильно, необходимо четко понимать, какие задачи на предыдущем этапе завершены, а какие нет. Без явных критериев завершения невозможно определить, когда задача готова к переходу на следующую стадию, что нарушает принципы потока ценности и эффективности DevOps подхода.