При вопросе, стоит ли использовать какую-либо технологию в рамках одной организации или консорциума, выбор ее правильного сценария использования – существенная часть конечного успеха по ее адаптации. Ведь, выбрав неправильный сценарий, есть большой риск не добиться результата и разочароваться в технологии. Причем дело-то будет абсолютно не в ней, а в неверном ее применении. Компаниям свойственно откладывать различные технологии в сторону и не внедрять их в дальнейшем, если они не видят быстрых результатов от их использования. Чтобы этого не произошло с блокчейном, автор решил сделать некое резюме подходов к выбору сценариев использования технологии на базе российского и международного опыта пилотных проектов.
Типы сценариев для пилотного проекта
Очевидно, что для успешной адаптации технологии необходимо изначально выбирать сценарии использования, ориентированные на ее сильные стороны. Обращаясь к определению блокчейна, это технология распределенного хранения информации в цепочке блоков или, другими словами, технология распределенных реестров. Главными преимуществами являются:
• неизменность записей в этой цепочке;
• распределенная ответственность между участниками бизнес-сети;
• возможность реализации бизнес-логики на базе смарт-контрактов.
То есть можно создать единый надежный реестр учета различных активов между несколькими организациями, где вся история взаимодействия между ними будет защищена от изменения в случае попыток мошенничества.
Обращаясь к российскому и международному опыту пилотных проектов в области блокчейна, можно сформулировать четыре основные группы сценариев использования технологии.
Группа сценариев №1: внутренний реестр в рамках одной организации для решения собственных задач
С одной стороны, блокчейн куда более эффективен при взаимодействии между разными компаниями, потому что дает возможность создать механизм доверия для не полностью доверяющих изначально друг другу лиц. И возвращаясь к тезису из предыдущего абзаца, логично использовать технологию там, где она дает наибольшие преимущества. Почему же тогда многие компании пробуют технологию у себя внутри без взаимодействия с другими? Да, блокчейн в рамках одной организации не максимально эффективен, но, во-первых, речь ведь идет о пилотном проекте. Во-вторых, компании осознанно идут на то, что не используют все преимущества технологии, а именно возможность распределения ответственности. Они фокусируются на преимуществе блокчейна в защищенности и неизменности истории. Зачем же отказываться от одного из преимуществ? Дело в том, что практика создания консорциумов показала, что компании плохо умеют договариваться друг с другом без участия регулятора. Отсутствуют правовые нормы, непонятны форматы – словом, быстрого результата не достичь, много времени тратится как раз на формулировку этих стандартов взаимодействия. Консорциумы начинают сильно расширяться, дополняться участниками: все больше времени начинает уходить на согласование действий и все меньше – на реальное пилотирование. Поэтому компании готовы отказаться от одного из преимуществ технологии для достижения быстрых, пусть и менее значимых результатов.
Типичным примером такого сценария является хранение истории операций в блокчейне для нужд аудита, отчетности или для соответствия норм регулятора. Почему организации идут на это? С точки зрения бизнес-кейса блокчейн все равно добавляет ценность в работу компании, упрощая аудит и в перспективе снижая его стоимость. То есть после проведения пилота возможны следующие действия: расширять его на небольшую сеть компаний-партнеров, реализуя преимущество в создании распределенной ответственности, и использовать результаты пилота для разработки продуктивной системы для собственных систем аудита, используя накопленный опыт. Таким образом, нет нужды выбирать другой сценарий использования и начинать все сначала. Работа в пилотном проекте не будет проведена впустую, и результаты «не кладутся на полку», а доступны к дальнейшему использованию.
Минусом такого сценария является тот факт, что блокчейн – не единственная технология, способная решить проблему создания единой системы учета для аудита в рамках одной организации.
Примером реального пилотного проекта является совместная работа IBM и Credit Mutuel Arkea1, где главной задачей было повышение прозрачности процесса взаимодействия со своими клиентами.
Группа сценариев №2: Распределенный репозитарий информации в рамках небольшой группы компаний (общий журнал учета консорциума)
В отличие от предыдущего сценария, в этом случае речь уже идет о наличии небольшой группы участников блокчейн-сети или консорциума. Суть сценария – наличие общей информации для всех компаний-участников, которая может использоваться для проверок или учета. Примерами являются единый портфель собственности, единый кадастровый реестр, единая система учета застрахованных вкладов, торговый репозитарий. Блокчейн дает возможность создания распределенного реестра ключевой информации для всех участников консорциума. Обновление информации (например, переоценка собственности) должно быть согласовано всеми участниками при сохранении аудиторского следа для минимизации рисков.
Таким образом, в данном сценарии уже удается применить два ключевых преимущества технологии: распределенную ответственность и неизменность истории записей. Третье преимущество в виде реализации бизнес-логики на уровне смарт-контрактов практически не используется, так как распространяется именно служебная информация, причем больше в информационных или проверочных целях. Преимуществами такого сценария являются ценность информации, хранимой в распределенном реестре, а также прозрачность и надежность за счет наличия аудиторского следа. К этому можно добавить и третий пункт – повышение скорости проверок, так как на текущий момент информация в большинстве случаев хранится не у одной организации, а у нескольких. То есть обращение к каждой из них приводит к увеличению сроков получения данных. В случае хранения в распределенном реестре появляется возможность проводить такие запросы в режиме, близком к реальному времени.
Реальным примером такого сценария является кейс ABN AMRO, где банк и IBM совместно исследовали в рамках пилотного проекта возможность применения блокчейна для финансовой реструктуризации (Financial Recovery and Restructuring, FR&R)2.
Группа сценариев №3: Хранение и передача информации, не представляющей большой финансовой ценности
В предыдущем случае рассматривалось создание распределенной системы учета на базе блокчейна, а в этом сценарии к возможности хранения добавляется еще и передача данных. Причем важно, что данные, которыми обмениваются организации, не имеют большой финансовой ценности и могут быть видны всем участникам сети. Типовыми примерами такого сценария являются система голосования на базе блокчейна или отслеживание цепочек поставок. Важно, что обмен информации по типу «каждый каждому» в этой группе сценариев не требуется. С другой стороны, все большую роль начинают играть смарт-контракты, использующиеся для обеспечения логики передачи активов от одного узла сети к другому.
В случае использования блокчейна для управления цепочками поставок реализация такой группы сценариев направлена на создание механизма разрешения конфликтных ситуаций. Примером такого сценария использования является сама компания IBM, реализовавшая пилот подобной системы в рамках подразделения IBM Global Finance3.
Группа сценариев №4: Хранение и передача ценных активов
Данная группа сценариев направлена на использование преимуществ сети блокчейна по максимуму: здесь и распределенная ответственность, и неизменность истории записей, и реализация логики на базе смарт-контрактов. Типичным примером реализации являются платежные системы на базе блокчейна, где технология способна помочь организациям снизить накладные расходы и повысить скорость передачи. Также возможны сценарии по реализации расчетов по сделкам с ценными бумагами, торговле деривативами, сделкам репо по базе блокчейна. В данных примерах создается децентрализованная одноуровневая сеть, где любой участник сети может обмениваться информацией с любым другим участником (тип «каждый с каждым»). Очевидно, что эта группа сценариев является самой сложной к реализации, так как помимо технических аспектов содержит еще необходимость установления новых нормативно-правовых норм. Но и преимущества будут максимальны.
Примером из мировой практики, который соответствует данной группе сценариев, является работа IBM и Mizuho4. Задачей пилотного проекта ставится понимание реального использования технологии для операций с виртуальной валютой.
Из приведенных примеров видно, что сложность пилота возрастает от первой группы к четвертой. В то же время реальные примеры есть в каждой из них. Какую из них выбрать лично вашей компании – решать только вам.
Отсюда следует:
1. Несмотря на очевидное преимущество блокчейна в создании децентрализованной сети обмена данными, пилотирование лучше вести сначала в рамках одной организации, а потом уже вовлекать партнеров.
2. Сначала лучше выбрать не бизнес-критичный сценарий с необходимостью передачи или хранения активов с высокой стоимостью, например, решающий реальную проблему.
3. Целью пилота не должно быть стремление максимально быстро перевести блокчейн в продуктивную среду, а максимально полное исследование технологии с разных стороны с анализом потенциально узких мест.
Итак, вы готовы выбрать первый сценарий для пилотирования. Можно ли сделать первоначальную прикидку, будет ли его реализация сценария эффективна на блокчейн? Ниже поговорим об этом.
Проверочные вопросы
Для первоначальной оценки того, подходит ли технология блокчейна для выбранного бизнес-сценария, предлагаем проверить сценарий по ряду вопросов. То есть составить некий «чек-лист» сценария для пилота. В самом начале логично найти ответы на общие вопросы, такие как:
1. Понятны ли бизнес-выгоды от реализации сценария на блокчейн? Можно ли сформулировать количественные показатели успешности завершения пилота?
2. Известен ли список участников создаваемой бизнес-сети?
3. Определен ли список передаваемых активов и список их владельцев?
Стоит отдельно подчеркнуть, что крайне важно оценить, что нового и ценного привнесет технология в работу организации: будут ли снижены расходы, появится ли новая модель бизнеса и т.д. Причем крайне важно понимать количественные показатели для критериев успешности проекта в целом. Зачем на это лишний раз обращать внимание? Дело в том, что из-за большого интереса рынка к технологии получилась некая гонка: быть первым, кто пропилотирует технологию, и получит результат. Само качество результата при этом, как оказывается, не столь важно. Здесь стоит задуматься: а хотите ли вы участвовать в этой гонке ради того, чтобы объявить рынку чуть раньше о проведенном пилоте, или сосредоточитесь на достижении результата и, в перспективе, конечном внедрении технологии в продуктивную среду?
В следующей группе вопросов про участников сети помимо определения их перечня важно обращать внимание на следующие факты:
• Действительно ли в рамках предполагаемого сценария нужно большое взаимодействие между участниками сети?
• Определен ли процесс взаимодействия между участниками сети и существуют ли контрактные обязательства для этого?
• Как будет осуществляться координация взаимодействия в сети?
Также важно иметь ответы на следующие вопросы про передаваемые активы:
• Как будет определяться владелец передаваемого актива в сети?
• Известен ли объем активов в сети и порядок из изменения?
• Определен ли жизненный цикл актива?
• Необходимо ли вести историю изменения статусов актива?
• Определены ли правила передачи актива?
Не стоит забывать и о вещах, связанных с транзакциями сети. Помимо того что необходимо понимать общий объем транзакций, важно оценить следующее:
• Каково соотношение операций чтения к операциям записи?
• Есть ли потребность в чтении большого числа исторических данных?
• Будет ли приемлемо для бизнеса, если транзакция станет выполняться за минуты (не миллисекунды и не часы)?
Таким образом, формулу хорошего сценария для пилотирования в общем виде можно представить следующим образом:
Успех пилота =
грамотно спланированная бизнес-сеть участников
с набором правил работы +
определение характера транзакций +
понимание передаваемых активов по сети +
количественные показатели успешности завершения
Очевидно, что это отнюдь не весь перечень вопросов, ответы на которые должны быть получены в результате подготовки к пилоту. Но международный и российский опыт показал, что многие пилотные проекты начинаются без ответов даже на приведенные вопросы. Как правило, в большинстве случаев эти пилоты не бывают успешными. Подготовка ответов снижает риск неудачи проекта и помогает правильно идентифицировать бизнес-кейс для пилотирования. И в дополнение – понять, к какой группе уже существующих пилотов можно отнести ваш сценарий и на какой международный опыт ориентироваться.