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

Процедура мини-расследования (major incident review) после устранения major-инцидента включает анализ всех факторов инцидента, формирование отчета с рекомендациями по предотвращению аналогичных ситуаций в будущем, оценку эффективности действий, предпринятых во время управления инцидентом. Результаты расследования обсуждаются с заинтересованными сторонами, и на их основе могут быть зарегистрированы проблемы, известные ошибки, либо предложены меры по улучшению ИТ-услуг (например, через service improvement plan или реестр CSI).

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

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

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

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

Пять основных областей применения руководителя проектов при переходе к гибким методам: 1) Управление работами команды - но эта роль обычно отводится владельцу продукта; 2) Построение работы команды - обычно осуществляется лидером команды или agile-коучем; 3) Управление проектом создания продукта - временная роль, необходимая только до создания MVP; 4) Управление результатами на более высоком уровне - в методологиях типа SAFe для этого разработаны другие механизмы; 5) Построение взаимодействия между старым и новым мирами - именно в этой области руководитель проектов может принести наибольшую ценность, обеспечивая координацию, синхронизацию, развитие и сопровождение процессов между традиционными и гибкими методологиями, особенно в бимодальных ИТ-средах.

Преимущество уточнённого определения Nj при расчёте FTR заключается в том, что оно позволяет точно отразить качество работы каждой отдельной рабочей группы. Учитывая только завершённые обращения (Cj + Sj), метрика исключает влияние незаконченных процессов, которые могли бы исказить результат. Это обеспечивает прозрачность и точность измерения эффективности групп, что важно для выявления слабых мест и оптимизации процессов управления инцидентами.

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

Измерение Flow Efficiency важно потому что оно позволяет выявить долю времени, когда над задачей фактически ведется работа, по сравнению со временем, проведенным в ожидании или в очередях. Это помогает командам понять, сколько времени теряется из-за простоя и ожидания, и сконцентрировать усилия на сокращении этих потерь. По утверждениям авторов 'DevOps Handbook', поскольку именно Lead Time воспринимается заказчиком как время выполнения работы, оптимизация именно этого показателя должна быть приоритетной. При этом соотношение времени обработки к общему времени выполнения является важной мерой эффективности процесса.