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

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

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

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

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

1. Бэк-офис, состоящий из собственных сервисов компании.
2. Бэк-офис из сторонних систем.
3. Фронт-офис, включающий основные интерфейсы проекта.

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

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

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

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

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

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

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

1. Хранить все файлы в едином модуле, с которым связываются все бизнес-процессы. Если у вас одна только CRM, то все документы можно без проблем держать в ней. В экосистеме же, как правило, десятки различных систем. Вытаскивать нужные файлы из CRM в таком случае неудобно: контакт с документацией лучше реализовать на уровне общего хранилища, настроив доступы к конкретным песочницам.
2. Создавать версионность доступа к файлам с гибкими правами для разных участников: как внутренних, так и внешних (партнёров).
3. Индексировать все документы в Word, Excel, PDF и изображения по их названиям и содержимому.

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

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

• автоматическое напоминание о встрече через предпочтительный для него канал: SMS, WhatsApp или любой другой;
• чеклист менеджеру: что не забыть во время встречи;
• SMS клиенту с целью оценить качество обслуживания;
• автоматическая генерация договора на основе шаблона;
• согласование договора с начальством.

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

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

1. Прошлое — аналитика. Эти данные уже собраны в хранилище, из них выделяются нужные срезы, далее в модуль аналитики закладываются алгоритмы обработки данных и автоматического формирования отчётов. Например, сюда относятся отчёты о движении денежных средств.
2. Настоящее — учёт. Как правило, это план на текущий месяц или другой период, за который нужно понимать, на ком какие задачи и KPI.
3. Будущее — прогноз. Здесь важно определить, какие участки бизнеса планировать и какая информация для этого требуется. Это может быть план продаж и план прихода.

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

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

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

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

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

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

1. Можно выстраивать абсолютно любой кастомный набор сервисов. Если уже после внедрения какая-то система перестала устраивать, её можно безболезненно заменить. Данные и связи не пострадают.
2. Экосистема будет максимально защищена от сбоёв. Даже если у вас упадёт файловое хранилище, CRM и все остальные системы при этом не пострадают и продолжат работу. На время устранения неполадок их функциональность будет ограничена, но не более того.

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

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

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

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

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

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

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

1. Доступ нужен не всем участникам экосистемы, а только некоторым. Представьте станок на заводе — образно говоря, это узкоспециализированное ПО. Всем менеджерам доступ к нему получать совершенно необязательно. Ключевые показатели, бизнес-процессы и отчётность по работе станка у них есть в других частях экосистемы. Главное, не забыть его интегрировать, иначе данные могут передаваться некорректно.
2. Полноценное ПО из примеров выше, как правило, не содержит удобного веб-интерфейса, поэтому бесшовно встроить его в ядро экосистемы либо невозможно, либо очень дорого.
3. Это опять же вопрос безопасности.

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

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

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

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

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

Два примера:

1. Выбор рекламных креативов и предложений для показа зависит от условий, полученных во время агрегации и аналитики данных. Допустим, мы знаем пол или возраст, значит, можем показывать более персонализированное объявление.
2. Как сегментировать аудиторию, зависит от истории взаимодействия и покупок пользователя. Нет смысла предлагать вторую квартиру тому, кто только что взял ипотеку. Зато ему может быть интересен ремонт или рефинансирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: