Подписаться
Читать в телеграм
Телеком-операторы со своей стороны включают защитные механизмы, позволяющие им эволюционировать из «трубы» в подобных поставщиков, т.е. реализуют концепцию PCC (Policy Control and Charging). Такая эволюция не может произойти в короткие сроки. Но на период этой трансформации в запасе у оператора есть ряд эксклюзивных активов, рациональное использование которых может увеличить его роль в предоставлении качественных сервисов прямо сейчас. Это наличие интерактивных каналов взаимодействия с абонентом, лояльности пользователей к бренду телеком-оператора; актуальных данных о геопозиционировании абонентов. Огромную ценность также представляет информация об абонентском профиле, фактической структуре потребления сервисов пользователями, структуре абонентского трафика.
За счет этих актвов оператор может попытаться достаточно быстро увеличить монетизацию или повысить конверсию абонентских средств (в траты), внедряя новые и актуальные сервисы. Компания может попробовать решить эту задачу в одиночку, но для нее это не выгодно в силу ряда причин – динамически меняющегося рынка абонентских сервисов, наличия огромного количества уже существующих популярных сервисов, их узкой специализации и нишевости, необходимости держать большой штат дополнительных сотрудников (аналитиков, программистов, тестировщиков) и др.
Рис. 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 смещается в сторону предоставления абонентам разнообразных специализированных сервисов.
