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

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

Практика описания потоков ценности (и формирования их как артефактов управления бизнесом) сформировалась в ходе эволюционного развития идей гибкой разработки.

Наиболее часто встречающийся подход к описанию потоков ценности состоит в том, чтобы включить в него работу конвейера CI/CD, начиная со сбора требований в бэклог, а заканчивая доставкой “ценности” до продуктивной среды и получение обратной связи от потребителя этой самой добавленной ценности.

На мой взгляд, этот подход имеет определенные слабые места.

Во-первых, в такой поток ценности не включаются операционные активности, не связанные напрямую с формированием той или иной “порции” ценности. Примером таких работ могут стать работы связанные с предоставлением ценности группе заинтересованных лиц, отличной от целевого потребителя услуг и товаров.

Например,  если наш поток направлен на развитие некоторого финансового сервиса (страхование) для внешних клиентов, то формирование ежедневной финансовой отчетности для владельцев компании (для оценки бизнес эффективности работы продуктовой компании), а также регламентированная отчетность для регулятора (Банк России) не станут частью потока. Нет сомнений, что эта деятельность все равно будет выполняться проектной командой, на нее будут тратиться ресурсы, что сразу создаст вопрос определения приоритета. При этом придется пройти через споры: “это нецелевая деятельность, значит это потери и это делаться не должно”.

Деятельность, связанная с использованием закупаемых ресурсов, например мониторинг и резервирование (включая тестирование надежности) существующих каналов связи до оборудования в ЦОД, учения по непрерывности тоже не попадут в поток. Можно не заниматься этим и закрывать на вопросы подтверждения надежности глаза, до поры. А дальше начнется: кто? когда? это же потери для нашего потока!

Во-вторых, подход “мы развиваем продукт и сервисы на его основе”, опираясь на некоторую обратную связь отталкивает тем, что для объективная ценность для целевого потребителя лежит не в том, что “сервис становится лучше из-за каждого изменения прошедшего через поток”. Ценность для потребителя заключается в факте, в живом акте потребления товара, услуги. Нет потребления – нет ценности.

Человек, который хочет застраховать машину по ОСАГО, получает ожидаемую ценность, грубо, в двух транзакциях: первая – приобретение полиса страхования (обретение права, страховой гарантии); вторая – получение страхового возмещения с определенной финансовой стоимостью в случае наступления страхового случая.

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

Классический подход к описанию потока ценности скажет нам: “Прекрасно. Мы принимаем это утверждение о потреблении ценности и будем соответствующим образом выстраивать улучшение предлагаемых услуг и товаров”. Например, мы создадим возможность электронного документооборота с другими страховыми компаниями регионального рынка так, чтобы страхователю не нужно было взаимодействовать с другими компаниями в рамках любых страховых разбирательств. Мы изучим рынок, создадим технологическую платформу, проведем договорную, юридическую работу, заключим соглашения и предоставим эту возможность нашему клиенту. Эта опция станет нашим конкурентным преимуществом, увеличит ценность приобретаемого страхового права за счет упрощения способов его реализации. Комплекс мер по созданию такой страховой опции без вопросов уляжется в конвейер, а что насчет мер по его поддержке? Ландшафт присутствия страховых компаний изменяется, ранее заключенные партнерские соглашения нужно регулярно пересматривать, необходимо контролировать и аккуратно вести взаиморасчеты с партнерами. От этой работы уже нельзя отказаться, мы декларировали эту ценность, она приобретена клиентами. Эта деятельность по поддержке – ответственность продуктовой команды, ведущей бизнес.

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

Какие выводы можно сделать из этого беглого взгяда на проблематику?

1. Поток ценности – это архитектура бизнеса, включая все его области и грани. Если вы больше всего думаете об ИТ, то вы имеете все шансы вернуться к “перебрасыванию кода через стену”.
2. Описание потока должно включать не только процессы “change the business”, но и “run the business”, в противном случае, вы имеете все шансы потерять ту самую ценность, которую так тщательно создавали.
3. Создаваемая в потоке ценность должна иметь ясное соотнесение с путем потребителя услуг и/или товаров.
4. Измерение реальной ценности должно происходить строго по актам потребления этой самой ценности. К слову сказать, измерение “полезности” от единичной добавляемой ценности может стать проблемой (см. пример документооборота между страховыми компаниями), т.к. прямого роста выручки ценность может и не нести, а измерение вклада опции в агрегированный показатель прироста числа клиентов может стать нетривиальной задачей.
5. Под словами “и все, все, все” в заголовке заметки подразумевалась конфигурационная архитектура процессов произвоства товаров и услуг, бизнес SCMS (устар., или CMDB, устар. дважды). Для того, чтобы описание потока создания ценности стало инструментом управления бизнесом, вам потребуется визуализировать поток, конфигурационную архитектуру, путешествие потребителя ценности и опираться в принятии решений и оценок на актуальные связи между ними.

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

З.Ы. В качестве “конфетки”: очень интересно рассматривать пример со страховой компанией, а именно с ОСАГО, в недавних реалиях российского рынка, когда страхование по фиксированным тарифам было очевидно убыточным, и компании включали в поток создания ценности такие мероприятия по улучшению “ценности” факта получения страхового возмещения, как перенос региональных страховых офисов, работающих с возмещениями, в тьму-таракань 🙁 .