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

Взаимодействие потоков ценности

Если мы посмотрим на любой существующий продукт и попробуем описать структуру управления им в терминах потоков направленной к потребителю ценности, то очень быстро станет понятно, что сделать это картой одного потока, скорее всего, не получится.

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

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

Критерий: природа ценности

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

Если продукт, условно, монофункционален, то видятся как минимум два потока ценности:

  1. Поток прямой эксплуатационной ценности, проводящий потребителя по его пути взаимодействия с компанией в процессе потребления продукта/услуг. Повторно акцентирую ваше внимание на то, что это именно поток создания ценности, каждый этап которого выражен в терминах получения ее потребителем, а не процесс обслуживания клиента, описываемый в терминах процедур, входов и выходов (см. “Поток как инструмент управления”).
  2. Поток продуктового развития, ценность которого направлена на изменение потока прямой эксплуатационной ценности. Этот поток создается для того, чтобы итоговая получаемая потребителем ценность росла. Создание и увеличение добавочной ценности – назначение этого потока. Результаты, за счет которых эта добавочная ценность будет увеличиваться, могут быть работами по развитию продукта, услуг, приложений, инфраструктуры, компетенций и возможностей, организационных преобразований. Не думайте об ИТ-составляющей, как об исключительной границе работы этого потока, ИТ – это только часть системы управления, значимая, но не самостоятельная.

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

Если продукт коммерческий (пусть далее это будет предполагаться, для простоты), то потребление продукта и услуг на его основе, формирует денежный поток. Перед продуктом может быть поставлена цель по его рентабельности.

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

Целевые значения показателя рентабельности, объема генерируемой прибыли должны и будут расти. Достижение этих показателей возможно только за счет того, что реализуя поток развития, добавляемая ценность делает продукт и услуги исключительными для потребителя. Создание возрастающего спроса и возможностей по его удовлетворению – задача потока развития.

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

Мысли о взаимодействии между процессами

Что же будет происходить “под капотом”, если мы посмотрим на потоки не снаружи (контролируя), а внутри (решая задачи): 

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

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

Что такое “добавить кнопку на страницу”

В 2014 году компания Twitter попробовала реализовать инициативу по созданию кнопки “Купить” под рекламными сообщениями пользователей. Нужно осознавать, что появление такой кнопки не является проектом “надо добавить на страницу кнопку? Не вопрос: bootstrap, JScript, MongoDB … Уже на проде! Пользуйтесь!”. Эта кнопка представляла собой отдельный, новый для Twitter вид бизнеса – площадка для партнеров по продаже их товаров релевантным заинтересованным аудиториям подписчиков. Весь остальной бизнес Twitter был основан на рекламной модели, продаже привилегий бизнес-аккаунтам.

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

Команда потока развития кнопки “Купить” может конфликтовать или пересекаться с командой развития социального контента Twitter в части ИТ-ресурсов (участия компетентных специалистов в первую очередь), т.к. и то и то – части одного продукта “Twitter”.

Внимательный взгляд на ценностный поток “старого” Twitter выявит двойственность. Различимы, как минимум, две разных ценности:”легко и удобно коммуницировать, делиться информацией или получать ее” (потребители – люди, простые бесплатные подписчики, будущая аудитория, C2C), и “получить устойчивую конверсию заинтересованной аудитории в выручку от продаж”, (потребители – компании, B2C). Эти ценности для разных пользователей сервиса Twitter связаны через формируемую аудиторию, но принципиально отличаются по характеру. Значит, они могут быть разделены по разным потокам. Но с принятием такого решения есть сложность: их ценность несравнима, т.к. ценность первого из них не измеряется в деньгах, в лучшем случае, в цифрах прироста аудитории, в качествах ее активности, отзывчивости сообществ на происходящие вокруг них изменения.

Если все же ввести такое разделение, то в Twitter будет три взаимосвязанных блока потоков ценности (эксплуатационная и развитие):

  • Community;
  • Advertising;
  • Marketplace. 

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

Эти потоки взаимодействуют? – Да, очень тесно, т.к. они могут предоставить ощутимую ценность своим пользователям только в синергии.

Будет ли такое разделение ценности по продуктам правильным, наилучшим? Трудно сказать, не обладая более подробными знаниями о компании и ее бизнесе.

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

Будут ли эти потоки конфликтовать за ресурсы? Конечно, будут.

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

Выводы

  • Задача описания бизнес-архитектуры в терминах не имеет простых решений, т.к. у каждой компании и продукта доносимая по пользователя ценность своя, и она достигается уникальными способами, с учетом уникальных взаимодействий между потоками.
  • Value stream mapping – это важная задача руководства, делающая воспринимаемую ценность бизнеса для потребителей наглядной и измеримой.
«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • Леонид

    Как я понимаю, поток “1” это поддержка, поток “2” это разработка. Первый поток вполне может быть выстроен по старому доброму ITIL2, а второй поток, например, по водопадной модели. И в чем тут новизна подхода, пара «новых» терминов и все?

    • Нет, не так.
      Первый поток, это не поддержка, это фактическая бизнес-деятельность направленная на конечного потребителя. Для ее описания в модели управления, как мне кажется, более всего подходит “нотация” из бережливого производства (см. англ. wiki по “Value-stream mapping”).
      Хочу отметить важное отличие описания процессов от потока ценности. Описание бизнес-процесса – это формальное описание той или иной деятельности (триггерных событий, шагов, их последовательности, входов, выходов, ресурсов), описание говорит о том какие конечные результаты, артефакты будут получены в ходе и по завершению процесса. (Поступил заказ/заявка/звонок, зарегистрировать карточку события, связать карточку с классификаторами, в зависимости от условий передать … группе обеспечения мобильности пассажиров, … )
      Описание потока имеет дополнительный слой, который будет лежать над процессами. Пример – фрагмент: приобретение страховки. Конечный результат этого действия – приобретенное право на возмещение потенциального ущерба. Для того, чтобы это право было прибретено, нужно: идентифицировать потребность в страховании, получить возможные опциии возможности предложений рынка страхования для анализа, выбрать наилучший вариант по ряду персональных критериев, обратиться в нужную страховую компанию, заключить сделку. Это путь, который нужно пройти потребителю, чтобы достичь желаемого результата. Теперь давайте подумаем о ценности, которую мы может дать потребителю на каждом шаге. В наихудшем случае, мы ничего не будем делать для потребителя: пусть сам осознает, что его текущий договор страхования закончился, сам прочитает 1001 предложение, сам разберется в возможных опциях и их вариациях, проведет несложные вычисления для выбора наилучшего, придет в офис компании пешком, заполнить строгую форму на бланке ДКС-2312, сразу оплатит и тутже станет счастливым обладателем права на компенсацию. Этот подход имеет право на жизнь, но на не очень долгую, в условиях хоть какой-либо конкуренции предложений. Значит компания на определенных шагах должна предоставить потребителю ценность, и делать она это будет с использованием одного или нескольких процессов, о которых мы говорили выше.
      Посмотрим на последний шаг цепочки – заключение сделки. Ценность этого шага можно разбить на два блока: совершение финансовой транзакции в сторону страховщика и обеспечение легитимности сделки и достоверности права. Транзакция может быть осуществлена: наличными, через агента, банковским переводом, платежом из приложения, и т.к. для каждого их этих способов существует бизнес-процесс обработки этих транзакций со своими триггерами, входами и выходами. Подтверждение легитимности сделки осуществляется через контроль валидности лицензии страховщика на момент сделки, регистрации факта сделки у регулятора, подтверждение легитимности финансовых средств, корректное юридическое-документальное оформление сделки и приобретенного права. Все это – компоненты итоговой ценности для потребителя, каждый из которых достигается через результаты детерминированных процессов.

      Второй поток, это деятельность по изменению бизнес-деятельности, направленная на увеличение конечной результирующей полезности.

      Если оставить своими рамками разработку и поддержку приложения, продолжая перекидывать его через стену условному пользователю, то да, нескольких отдельных процессов из ITIL 2 и 3 версии будет вполне достаточно для описание деятельности, но не ценности в ней.

      Надеюсь, что мне удалось ответить на ваш вопрос. Спасибо за комментарий.

      • Леонид

        Спасибо за развернутый ответ, Андрей. Бизнес процессы и предоставление ценности клиенту компании это, конечно, хорошо, однако мы тут про ITSM и, например, внутренняя ИТ служба предоставляет своему клиенту (бизнесу) ценность в виде разработки и поддержки некоего функционала. Получается, что для работы реального ИТ «новые» подходы предлагают лишь новые термины?

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

          Задача описать систему управления потоками, ценностным языком возникает тогда, когда компания пытается осознать (а дальше по списку: измерить и улучшить, сделать конкурентным преимущетсвом) свою внутреннюю эффективность. Есть большая компания или холдинг, одних ИТ-сотрудников 1000+ человек. Как оценить их вклад? Как гарантировать/обеспечить рост эффективности бизнеса, с учетом таких непрозрачных колоссальных “накладных” расходов?

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

          • Леонид

            Зачем флагом цифровизации машут интеграторы ясно, они кушать хотят, надо продать очередной «айфон». Но хочется понять, чем новые подходы полезны в Real ITSM, что конкретно внутренняя ИТ-служба может предложить бизнесу, кроме «разработки и поддержки функционала»?

            • Предлагаемый способ позволяет целостно взглянуть на задачу доставки функционала бизнесу. Если вернуться к моему комментарию, где я описываю шаг “заключение сделки”, про транзации, легитимность и т.д., то именно на этом шаге становится очевидным, что ИТ будут предлагать инструментарии и решения для осуществления этих самых проверок и транзакций. Этих ИТ-решений будет много, их нужно интегрировать – это именно та ИТ-кухня, которая всем нам близка и знакома.
              Направление “от ценности к инструментам”, дает возможность понять не только что именно мы делаем, но и зачем это все, каких вещей (это интеграции почти всегда, или параметры гарантии/сервиса) бизнесу не хватает, а какие решения становятся в своем развитии уже избыточными.

              • Леонид

                Андрей, в своих примерах вы упорно пытаетесь научить бизнес, как ему лучше работать. ИТ-службу редко пускают в такие сферы. Для нас цепочка создания ценности начинается с запроса бизнеса (demand) и заканчивается предоставлением некоего функционала, обеспечивающего решение бизнесом своих задач (value). Конечно, выбор инструментария и решения, обеспечивающего функционал, задача ИТ. Этот функционал по прошлой моде часто называют сервисом, а его разработка и поддержка и есть для нас поток создания ценности, внутри которого давно выстроенные процессы. Получается, новая терминология легко натягивается на старые структуры. Боюсь, интеграторам придется затянуть пояса.


Добавить комментарий для ЛеонидОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM