Портал №1 по управлению цифровыми
и информационными технологиями

Value stream, user’s journey и все, все, все.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 4

  • Nargiza Suleymanova

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

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

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

      • Nargiza Suleymanova

        Какая из ценностей весомее – это примерно как определять какой из процессов важнее 🙂 ответ простой – они все важны, но приоритизировать задачи в рамках разных потоков нужно. И это зависит от конкретной организации, тут уж как с бизнесом/заказчиком договоришься, так и будет. Задача нетривиальная обычно )

  • Sinan Aliyev

    Был такой термин VBF в третьей версии. Vital Business Function. Самая важная функция услуги, где все остальные становятся второстепенными или незаметными, если эта важная не работает. Если банкомат не выдает деньги, выдавать чек второстепенно. Или наоборот, выдал деньги, чек закончился, но это не так важно. То есть в этой функции сконцентрированна основные результаты услуги. Я думаю каждый заказчик и поставщик 80 на 20 знает какая это функция. Если не знает то можем определить. Хотя бы с помощью Kano Model-и. С помощью этой же модели можно определить и остальную добавочные результаты и ценность за ними. Но это всё пока только про Utility.

    Что если это стандартизированная услуга. Commodity какой нибудь. Здесь просто продать страховку, уже не дифференцирующая ценность. И кешбек и доставка на дом тут стандартизировано. Весь город продаёт страховку. Здесь уже Warranty вступает в силу. И изучаемый в 600 раз Value stream покажет новые инструменты оценки и улучшения ценности существующего много лет услуги.

    ПыСы: Кстати примеры с двумя транзакциями, это результаты услуги. (Например, получение финансового возмещения). Такой результат выдают многие страховые компании. Но выбираем мы ту или иную компанию, в зависимости от того как это услуга предоставлена. Результат от похода к парихмахеру, это стрижка. Ценность может быть, выглядить хорошо на свадьбе друга, постричься как можно быстро, постричься без пошлых анекдотов, стричься и быть выслушанным и тп. Вспоминая определение услуги – A service is a means of enabling value co-creation by FACILITATING OUTCOMES that customers want to achieve…….а также заметка про ценность – Value can be subjective.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;