Внутри цифровой экосистемы: как всё устроено

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

Рассказывает digital-интегратор DD Planet.

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

В основе экосистемы три блока:

Объединяет их корпоративная шина данных, которая передаёт информацию по всей экосистеме.

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

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

Единое хранилище данных. Речь про основополагающие данные: справочники компании, каталог товаров и услуг, но без информации о клиентах и контрагентах, — она хранится в CRM. Это сквозная информация, но сама система управления мастер-данными должна находиться именно в ядре. Именно отсюда запускаются основные бизнес-процессы, которые уже распространяют эти данные по всем остальным системам.

CRM и CDP. Как мы рассказывали в тексте «Какой бизнес может увеличить прибыль с помощью цифровой экосистемы», в CRM, помимо текущих и потенциальных покупателей, важно хранить все точки касания с компанией: заполненные формы на сайте или в соцсетях, куки пользователей, и другие данные, которые мы знаем о человеке. Информация в CRM заводится автоматически после онлайн-действий или вручную, если клиент пришёл, скажем, в офис продаж.

Далее данные анализируются и склеиваются. Это можно делать не только в бэк-офисе, но и с помощью самого клиента. Такая практика существует в ecommerce: если покупатель теряет карту лояльности, а приложение определяет, что она была, то предлагает человеку объединить данные. После склейки данных в CRM формируется единый ID, уникальный для каждого пользователя. В результате CRM расширяется до Customer Data Platform — платформы клиентских данных.

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

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

Из базового — бизнес-процесс проведения встречи с клиентом:

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

Аналитика и отчётность. Когда у бизнеса много данных, важно понимать, какие из них необходимы для аналитики:

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

Условный пример: у человека нет автомобиля, но он интересуется покупкой недвижимости. Мы можем предположить, что он уже сейчас уверенно стоит на ногах и в скором времени ему понадобится и автомобиль.

Маркетплейс. Важный элемент для построения горизонтальной экосистемы, которая предполагает работу с партнёрами. Здесь необходимо понимать особенности конкретного сегмента бизнеса и основные процессы в нём. Бизнес-процессы должны быть универсальны и понятны пользователю, чтобы в первую очередь ему было удобно и соблюдался принцип win-win. Например, если говорить про заправки, важно, чтобы маркетплейс был обучен бизнес-процессам заправок, понимал порядок действий пользователя, единицы измерения бензина.

Далее выстраиваем архитектурную стратегию маркетплейса: регламентация процессов, сбор данных, определение входов-выходов для партнёров, механизмов подключения к API и формирование дальнейших правил игры.

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

В чём шина данных выигрывает у прямого подключения систем друг к другу:

Взаимосвязь ядра с остальными блоками экосистемы происходит только через внутреннюю шину данных. Снаружи она доступна только для внешней общей корпоративной шины данных: она отдаёт ей все данные из ядра и получает внешние. Напрямую подключать их к общей шине нельзя. Данные, которыми обмениваются с внешними системами, должны быть чётко отделены от внутренних, и к ним должны применяться усиленные правила безопасности.

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

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

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

Правильный вариант: зафиксировать факт отказа и попытаться отправить данные ещё раз.

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

Почему специализированный инвентарь лучше выделять в виде отдельного сегмента экосистемы:

К этому блоку относятся внешние сервисы, контролируемые другими компаниями.

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

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

Рекламные системы. Интеграции с системами коллтрекинга, счётчиками Google Analytics и Яндекс.Метрики и настроенными сегментами в рекламных системах есть у многих, однако сами по себе они ещё не образуют экосистему.

В этом случае предполагается обязательный обмен данными с остальными сервисами. Это помогает эффективно управлять рекламой, опираясь на прогностические модели.

Два примера:

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

SSO. Single Sign-On — единая авторизация через соцсети, email, Госуслуги и другие сервисы, реализация собственного сервиса SSO для других частей экосистемы.

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

Фронт-офис — то, что видят все пользователи и партнёры экосистемы.

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

Мастер создания сайтов спецпроектов. Многие компании делают отдельные лендинги или спецпроекты для рекламы определённых товаров и услуг. В ecommerce лендинг можно создать для группы товаров или одного товара. В недвижимости — для ЖК или даже квартиры.

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

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

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

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

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

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

Для такого игрока необходимо создавать отдельный личный кабинет, потому что, в отличие от партнёров из предыдущего пункта, у него может быть больше рычагов или, наоборот, более узконаправленные функции. Например, в сфере недвижимости к таким организациям относятся управляющая компания или сотрудник ЖКХ, в ecommerce — курьерская служба.

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

Источник: