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

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

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

Конкретные проблемы взаимодействия ИТ и бизнеса, которые не видны на производстве, включают: сорванные сроки выполнения проектов, невыполненные обещания, заметное отставание от конкурентов, бесполезно потраченные ресурсы, постоянное изменение правил игры, неспособность предлагать инновации, отсутствие прозрачности в работе. Эти проблемы влияют на P&L компании и личные бонусы руководителей, но происходят не в основных производственных процессах, а в управлении и стратегическом планировании.

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

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

Целевые состояния — это промежуточные точки развития продукта, которые определяют, каким должен стать продукт через определенные промежутки времени (несколько месяцев). Они представляют собой набор потребительских свойств, которые продукт должен приобрести для продвижения к своей конечной цели. В контексте дорожной карты целевые состояния служат основой для планирования — дорогая карта визуализирует путь к достижению этих состояний. Достижение целевых состояний идет этапами, которые называются вехами развития продукта. Дорожная карта использует целевые состояния вместо конкретных требований, что позволяет сохранить более высокий уровень абстракции и гибкость в планировании, так как требует меньше детализации в долгосрочной перспективе, где изменения неизбежны. Это также помогает избежать ситуации, когда план повторяет лишь содержимое бэклога, разбитое на кучки по месяцам, что является вырожденным вариантом использования дорожной карты.

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

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

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