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

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

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

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

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

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

"Fit for use" - это термин, который описывает характеристику Warranty (Гарантия) услуги. Он означает, насколько услуга находится в том состоянии, чтобы пользователь мог ею пользоваться без проблем. "Fit for use" определяется четырьмя компонентами: доступность (может ли пользователь получить услугу, когда это необходимо), мощность (достаточно ли ресурсов для удовлетворения запросов), безопасность (защищена ли услуга от несанкционированного доступа) и непрерывность (насколько услуга устойчива к перебоям). Например, если свет в комнате мигает, то при его высокой полезности (способности помочь читать в темноте) он имеет низкую пригодность к использованию из-за нестабильности работы.

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

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

Реактивная часть управления доступностью относится к учету и регистрации фактов и периодов недоступности услуги. Она включает мониторинг и измерение доступности через фиксацию инцидентов недоступности. Этот процесс позволяет отслеживать, когда и как долго услуга была недоступна, а также выявлять причины и последствия простоев. Особенно важно это при массовых инцидентах, которые имеют высокую вероятность стать инцидентами недоступности, так как они直接影响 точку потребления услуги и требуют коммуникации с пользователями.