Уход от «трубы»

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

Рис. 1. Архитектура Jet Digital Service Platform

Гораздо разумнее вступить в кооперацию с партнерами, чья узкая специализация заточена на предоставление специфичных сервисов абонентам. Но партнерам нужен удобный доступ (интерфейс) в экосистему оператора для максимального использования его возможностей. Для реализации этой потребности в телеком-мире существуют решения класса SDP (Service Delivery Platform). Подобное решение есть и у нашей компании – платформа Jet Digital Service Platform (JDSP). По каким причинам мы взялись за его реализацию? Во-первых, в нашей «копилке» наличествует ряд разработанных и внедренных платформ, которые служат базой для этого решения (Jet CDP (Content Delivery Platform) и Jet CPA (Content Provider Access)). Во-вторых, мы как интегратор обладаем огромным опытом и выявили ряд недостатков существующих на рынке SDP-продуктов.

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

В ходе проработки платформы мы сделали особые акценты на ряде факторов:

• Unified Customer Experience – решение должно обеспечивать единые ощущения для абонентов при использовании как операторских, так и партнерских сервисов (предоставление достоверной информации по услугам, их стоимости, правилам использования, отказа, продления и т.д.);
• изоляция возможных негативных действий партнеров – проактивная защита абонентов;
• при запросах от партнеров готовность платформы к передаче любой обезличенной информации об абонентах и их активностях;
• возможность максимального использования существующей у телеком-оператора экосистемы, сведение к минимуму необходимости внедрения новых систем и платформ;
• гибко настраиваемый SLA для реализации ограничений на интерфейсах партнеров и на услугах, предоставляемых абонентам, включая механизмы динамического троттлинга, контроля fraud-лимитов и т.д.;
• единый абонентский Front Office по всем используемым сервисам;
• единый Back Office для служб Customer Care и партнеров;
• встроенные механизмы расчета потребления партнерами сервисов оператора с возможностью построения ответов различного типа;
• движок платформы со встроенным механизмом BPM (Business Process Management), позволяющий гибко конфигурировать реализованные бизнес-процессы и предоставляемые абонентам услуги;
• толерантность платформы к экосистеме оператора, позволяющая при внедрении переиспользовать уже существующие системы и модули при наличии у них стандартизированных интерфейсов;
• реализация внутренней архитектуры платформы и ее внешних интерфейсов на открытых стандартах и протоколах.

Концептуально архитектуру JDSP можно разделить на ряд «уровней» (см. рис. 1). Кратко обозначим «начинку» и функционал каждого из них.

Уровень маршрутизации (Transports & Routing)

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

Уровень прикладных сервисов (Domain Services)

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

Уровень бизнес-логики (Business Logic)

Сценарии бизнес-логики реализуются в виде BPM-процессов (диаграмм) и выполняются BPM Engine. Для решения прикладных задач (нотификация, списание средств и т.д.) выполняется обращение к сервисам прикладного уровня. BPM позволяет декларативно описывать сценарии взаимодействия и исполнять их в контролируемой среде.

Поддержка отчетности (Reporting Support) и мониторинга (Monitoring Support)

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

Интерфейс администраторов, операторов и контент-менеджеров (Back Office)

Back Office системы реализован в виде «тонкого клиента» (web-интерфейс) и предоставляет доступ к ключевым функциям платформы.

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