При использовании causal loop diagram (CLD) в реальных ИТ-организациях возникают несколько практических сложностей. Во-первых, с расширением диаграммы (увеличением количества переменных) она становится практически нечитаемой, поэтому важно сохранять фокус на конкретной проблеме и не включать все возможные факторы. Трудность заключается в том, что в процессе анализа постоянно открываются новые факторы, и сложно определить, какие из них критичны для анализа, а какие можно пренебречь. Во-вторых, связи между переменными в реальной жизни могут быть не такими однозначными, как на диаграмме - например, большой Backlog Size не всегда приводит к увеличению Release Size, что зависит от конкретного случая и культуры организации. В-третьих, построение CLD требует глубокого понимания всех процессов и взаимодействий в организации, что часто недоступно одному человеку и требует командной работы. В-четвертых, даже при согласованной диаграмме сложно определить, какие именно точки воздействия будут эффективны для изменения всей системы. Тем не менее, несмотря на эти сложности, CLD остается ценным инструментом для визуализации и объяснения сложных системных явлений в ИТ-организациях.

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

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

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

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

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

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

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

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

Подход к установлению сроков в управлении проблемами принципиально отличается от сроков в управлении инцидентами тем, что в управлении инцидентами используются строгие «инцидентские» временные нормативы, часто измеряемые часами или днями, поскольку цель инцидента - быстрое восстановление сервиса. В управлении проблемами сроки диагностики уже измеряются неделями (например, 1-2 недели в зависимости от уровня влияния), поскольку задача заключается в глубоком анализе и нахождении корневой причины, а не в быстром восстановлении работоспособности. При этом полная обработка проблемы (включая внедрение решения) не нормируется едиными сроками, так как зависит от множества факторов, включая сложность изменений и периодичность проявления проблемы.