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

Учет рабочего времени при расчете Flow Efficiency для распределенных команд является сложной задачей, так как сотрудники могут работать в разных часовых поясах и иметь разные графики (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку). Точный расчет требует учета доступного рабочего времени каждого участника потока, но в условиях совместной работы над задачей неясно, какой календарь использовать. Практически все реализации сводятся к упрощенным подходам и договоренностям, а не к точному расчету, что делает получаемые значения приблизительными. Некоторые методы предполагают использование среднего календаря команды или выделенного ответственного, но ни один из них не дает идеального результата.

Уровень System Capacity Management определяется как управление мощностью на уровне информационных систем. Этот подпроцесс используется, когда ИТ-услуга ассоциируется с обеспечением работоспособности конкретных систем. Он включает в себя определение требований к производительности, надежности и доступности систем, а также трансляцию этих требований в ресурсные ограничения. System Capacity Management необходим при предоставлении услуг, ориентированных на систему (например, SaaS), но не требуется, если услуга определена напрямую как предоставление ресурсов.

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

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

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

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

Критичность отклонения оценивается через влияние сбоя на бизнес-процессы. Например, недоступность CRM-системы на час может привести к потере 100 заявок, а простой внутреннего почтового сервера — только к временному неудобству. Рекомендуется создать матрицу, где каждая услуга оценивается по шкале: 1) финансовые потери в час простоя, 2) число затронутых сотрудников, 3) регуляторные риски. Услуги с высокой оценкой по этим параметрам должны получать больший вес в обобщённом отчёте.

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

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