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

Поток как инструмент управления

Вернемся к идее использования потоков создания ценности в роли архитектурных элементов системы управления.

Вопрос о том, как сделать это целостно, беспокоит меня уже какое-то время. Первые размышления по этому вопросу удалось выразить в заметке “Value stream, user’s journey и все, все, все”. Размышления были захватывающими, но это было лишь начало: отдельные принципиальные области оставались открытыми.

Не было понимания, что делать с актом (или множественными актами) потребления услуги потребителем. Они, очевидно, не укладывались в “каноничный” поток развития, который проиллюстрирован сегодня в каждой книге. Акт потребления услуги, и осознания через это конечной ценности пользователем, нужно было укладывать в какую-то иную конструкцию.

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

Сейчас есть ощущение, что на эти вопросы можно дать ответы и нам удастся сформировать целостную картину управления.

Поток вместо бизнес-процесса

Давайте вернемся к примеру со страховой компанией. Можно выделить как минимум два инициирующих набора активностей вызванных актами потребления услуги:

  • приобретение страхового права;
  • получение страховой компенсации.

В стародавние, незапямятные, времена мы описали бы деятельность, которая происходит в организации-страховщике, бизнес-процессами: тригеры процессов детерминированы, шаги процесса ясны, выходы понятны и измеримы.

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

Очевидно, что такое описание будет самым существенным образом коррелировать с шагами пользователького пути “customer journey” и нашей деятельности по его фактическому осуществлению.

Такое описание сохраняет преимущества описания деятельности как последовательно-непрерывной, с сохранением всех присущих ей характеристик, таких как пропускная способность, узкие места, измеримость.

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

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

  • подтверждение страхового случая.

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

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

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

Из вышесказанного можно сделать только один вывод, в передовой страховой компании нет (не должно быть 🙂 ) такого пункта в списке потоков ценности.

Бездрайверные работы – это ресурсы

Потоки создания ценности, связанные с ее прямым нанесением потребителю, опираются на отдельные ИТ и бизнес активы: системы, инструменты, API, экспертный труд специалистов.

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

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

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

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

Такое жонглирование ярлыком “ресурс” привносит еще два дополнительных наблюдения из которых можно сформулировать место этих “ресурсов” в формируемой накапливаемой ценности:

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

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

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

Резюме:

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

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

 

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

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

  • Петр

    Добрый день!
    В этой парадигме, покрытие системы автотестами и затраты на регресс – тоже ресурс?

    • Мне кажется, что нет. Это работы по развитию направленные на улучшение самого потока развития.
      Если мы развиваем и поддерживаем практику автоматического тестирования, то мы существенно уменьшаем lead time. Собственно, без автотестирования (как частного, так и общего регрессивного) полноценный автоматизированный конвейер Continuous integration доставки изменений до защищенной продуктивной среды невозможен.
      Ценность этого действия складывается из драматического влияния на lead time и из снижения затрат на устранение сбоев и донесенных до продуктивной среды ошибок. Реализация этого действия полностью лежит на продуктовой команде, ее ИТ-компетентных сотрудниках.
      Поэтому, эта инициатива должна как родная лечь в бэклог вышеупомянутой команды, и быть доведена до “ценнностного” завершения в рамках классического потока продуктового развития.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM