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

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

Управление проблемами существенно влияет на сокращение времени решения инцидентов, хотя часто его значение недооценивают. Если уменьшить общее количество инцидентов путем выявления и устранения их первопричин, это приведет к снижению нагрузки на персонал поддержки. Даже при одинаковой производительности сотрудников, меньшее количество инцидентов существенно снизит среднее время их решения из-за снижения очереди. Например, при 24 инцидентах в день (при условии их одновременного поступления утром) среднее время решения возрастает до 4 часов 10 минут, а при 12 инцидентах - падает до 2 часов 10 минут. Таким образом, управление проблемами влияет на процесс косвенно, сокращая поток инцидентов, что особенно важно с учетом неравномерного распределения инцидентов в течение дня (пиковой нагрузки в определенные часы).

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

Основные причины следующие: 1. Дочерним аутсорсерам не разрешают получать адекватную прибыль или применяется схема cost plus (1-2%), что мотивирует руководство аутсорсера на снижение эффективности для формирования запасов ресурсов. 2. Отсутствие жестких планов коммерческой деятельности на открытом рынке, что лишает аутсорсера стимулов к повышению качества и развития бизнеса, делая его инертным. 3. Вывод в аутсорсинг уникальных услуг, связанных с глубоким пониманием бизнес-процессов материнской компании. Это создает монополию на специализированные и базовые услуги, позволяя манипулировать ценами.

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

Для управления техническим долгом необходимо регулярно резервировать время и ресурсы команды на его выявление и продуктивное снижение. Следует работать над принятием стратегических архитектурных решений и применять антихрупкие паттерны построения приложений. Технический долг неизбежен, но важно, чтобы он возникал вследствие осознанных решений. Непродуманный технический долг снижает производительность, увеличивает количество дефектов, ухудшает тестирование и мешает мониторингу системы.

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

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

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