Почему BSS/OSS не надо ломать, а слой роста строить вокруг него

Три года, два миллиона долларов и неиспользованная коробка

В практике крупных программ модернизации в регионе встречается один и тот же сценарий. Оператор объявляет программу замены биллинга. Подбирают вендора, согласовывают сроки, начинают параллельный запуск. Через два года параллель не сходится. Старая система работает, новая работает на бумаге, бизнес говорит «мы не можем переключиться, у нас закроется отчётность за квартал». Программу переименовывают, бюджет увеличивают, потом тихо закрывают и возвращаются к точечной модернизации.

Эта история повторяется не потому что вендоры плохие. Она повторяется потому что биллинг и OSS в большом операторе — это не «система», это отражение тысячи настроенных бизнес-правил, исторических исключений и операционной памяти команды. Заменить такую систему — значит переписать эту операционную память. Что почти всегда длится дольше любого первоначального плана.

Альтернативный путь — другой. Не менять core, а строить рядом слой, в котором живут продукты, события, правила и партнёры. Этот слой называется around-core architecture, и в большинстве случаев он закрывает 70-80% потребностей цифрового роста, не трогая то что отвечает за деньги.

Откуда идея слоя роста

Разговор о замене BSS/OSS обычно начинается с правильного наблюдения. Текущая система не отдаёт события в реальном времени. Каталог продуктов сложен. Запуск нового тарифа занимает месяцы. Интеграции с приложением, контакт-центром и партнёрами — через ночные выгрузки. Это всё правда.

Но из правильного наблюдения делается неправильный вывод: «значит, нужна новая система». Правильный вывод другой: «значит, нам нужны современные интерфейсы, события и правила — но не обязательно вместо core, можно над ним».

Технологически это выглядит так: API gateway принимает запросы и обращения к core через стабильный слой контрактов. Event collector фиксирует все значимые состояния клиента — пополнение, активация, изменение тарифа, обращение в саппорт — и отдаёт их в реальном времени. Product catalog описывает офферы и тарифы в машиночитаемой форме, отдельно от того как они хранятся в биллинге. Offer engine принимает решения какой оффер кому показать в каком канале. Reconciliation сверяет потребление с биллингом с платежами. Audit trail хранит историю кто что делал. Observability показывает работу всего этого в одном экране.

Каждый из этих компонентов реализуется как отдельный сервис. Они интегрируются с core через стабильные интерфейсы. Сам core при этом продолжает делать то для чего он создан — учёт клиентов, тарификация, расчёт начислений, выставление счетов. Без него ничто не работает, но и менять его не нужно если он эту работу делает корректно.

Какие системы в архитектуре

Около десяти лет назад в типичном операторе было 3-5 ключевых систем. Сегодня это уже 15-25 интегрированных компонентов в любом крупном операторе. И именно на стыке между ними рождается значительная часть проблем цифрового роста.

В контуре around-core реалистичный набор такой. Core BSS отвечает за абонента, тарифы, тарификацию, начисления, биллинг. OSS — за сеть и provisioning. CRM хранит контакты и историю обслуживания. App backend — за функциональность приложения. Contact center использует данные из core и CRM. Dealer portal обслуживает розничную сеть. DWH/CDP хранит исторические данные. Campaign system отправляет коммуникации. Payment integrations соединяют с банками и платёжными провайдерами. Fraud monitoring следит за аномалиями. Finance reconciliation сверяет деньги.

Около этого зоопарка строится слой роста: API gateway, event layer, decision engine, observability. Это не семь новых систем — это нормализующий и оркестрирующий слой над уже существующими.

Где архитектура ломается на практике

Архитектурные диаграммы рисовать просто. Реализация ломается в трёх типичных местах.

Первое — данные. У клиента есть пять разных идентификаторов в пяти системах, и они не сходятся между собой. Один и тот же абонент в core имеет ID 1234567, в CRM — 78910, в приложении — UUID, в DWH — historical key. Master data management звучит скучно, но без него любой around-core слой превращается в набор предположений. Данные сливаются из разных источников, но решение по этим данным принимать опасно — потому что неясно, об одном клиенте речь или о двух разных.

Второе — события. Биллинг и OSS были спроектированы как batch-системы. Они умеют отдавать суточный отчёт, не умеют отдавать поток в реальном времени. Чтобы получить event-driven слой, нужно либо встроить в core CDC (change data capture), либо поставить event collector который шлёт события в момент когда они происходят. Это инвестиция в core, но небольшая по сравнению с заменой.

Третье — правила. В большинстве операторов бизнес-правила (eligibility, suppression, frequency cap) существуют в виде SQL-запросов в кампанийной системе или в коде маркетинговых модулей. Чтобы around-core слой работал, эти правила должны быть вынесены в decision engine как первоклассные объекты — с версионированием, тестами, аудитом. Это работа по систематизации того что годами писалось в разных местах.

Подходы и trade-offs

Есть три подхода к интеграции слоя роста с core.

Первый — встроить новую функциональность прямо в core. Кажется самым прямым: одна система, меньше интеграций. На практике даёт два больших минуса. Замедляет любые изменения, потому что всё привязано к билингу. И повышает риск, потому что bug в новом продукте может обвалить core который отвечает за начисления.

Второй — построить отдельный слой over core. Стабильный API между core и слоем, события через CDC или event bus, decision engine отдельный. Минус — сложность интеграции и операционная нагрузка на поддержание интерфейсов. Плюс — независимость скорости развития: продукты в around-core слое запускаются быстро, core стабилен.

Третий — купить vertical solution который умеет конкретный сценарий end-to-end. Например, готовый wallet или offer engine от вендора. Минус — vendor lock-in, новый silo, дополнительная интеграция. Плюс — быстрый запуск minimum viable product.

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

Risks, dependencies, constraints

Риски around-core архитектуры реальные, и их стоит обсуждать заранее.

Финансовая ошибка. Если decision engine выдаёт оффер с неправильным расчётом, ущерб может быть масштабным — пока не сработает reconciliation, оффер раздаётся всем подходящим клиентам. Защита — обязательный staging, frequency cap, manual approval на крупных кампаниях.

Privacy. Аroundcore слой работает с персональными данными интенсивно. Нужно явное согласие на каждое использование данных за пределами договорной обязанности оператора. Закон о персональных данных Узбекистана требует чёткой цели обработки. Без consent management слой роста может стать источником регуляторных проблем.

Fraud. Чем шире exposed API, тем больше attack surface. Дилерский портал, partner API, app backend — каждая точка интеграции потенциально может быть использована для повторных промокодов, фиктивных подключений, обхода правил.

Vendor lock-in. Если decision engine куплен у вендора без права на исходники и без переносимости конфигурации, через несколько лет миграция станет дорогой. В контракте критически важна clause о data portability и о праве доступа к conf файлам.

SLA. Слой роста должен работать минимум на уровне core. Если он падает, продажи останавливаются. Это требует HA архитектуры, monitoring, on-call процесса.

Когда замена core всё-таки оправдана

Around-core подход не всегда правильный. Есть условия при которых замена биллинга — единственный реалистичный путь.

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

Второе — когда модель биллинга принципиально не подходит к новым продуктам. Например, оператор хочет запускать subscription-based bundles с динамическим pricing, а core поддерживает только flat tariff с фиксированными правилами. Это не вопрос интеграции, это структурное несоответствие.

Третье — когда compliance требует функциональности которой в core нет, и добавить её невозможно по архитектурным причинам. Например, новые требования к real-time reporting в регулятор, которые batch-биллинг физически не выдаёт.

В этих трёх случаях замена оправдана, но даже здесь правильный паттерн — strangler pattern. Поэтапная миграция продуктов из старого биллинга в новый, с возможностью отката, без single big-bang.

Roadmap для слоя роста за 18 месяцев

Первые 90 дней — диагностика и базовая инфраструктура. Каталог систем и интерфейсов, master data plan, базовый API gateway, события для одного-двух pilot use case.

Следующие 90 дней — первый продукт. Один offer engine use case, один customer journey end-to-end, dashboard с экономикой пилота.

К 9 месяцам — расширение. Второй и третий use case, partner integration, observability на уровне всей системы.

К 12 месяцам — настройка операционной модели. Кто принимает решения, кто несёт P&L, как разрешаются конфликты между маркетингом и саппортом.

К 18 месяцам — масштабирование. Decision engine обслуживает основной поток коммуникаций, partner platform работает с 5-10 партнёрами, finance reconciliation замкнут.

Этот roadmap гибкий. Главное правило — не пытаться сделать всё параллельно. На каждой стадии выбирается доминирующая задача, остальные идут на бэкграунд.

Когда не строить around-core

Если у оператора менее 500 тысяч активных абонентов, инвестиции в around-core слой могут не окупиться. Простая модернизация core плюс CRM может закрыть потребности.

Если в команде нет архитектора с реальным опытом event-driven архитектуры, проект превратится в набор разрозненных интеграций без общей логики. Найти такого человека сложно, без него лучше не начинать.

Если бизнес-стратегия не определена и непонятно какие продукты будут запущены в ближайшие два года, around-core слой строить рано — слой проектируется под продукты, не наоборот.

Если бюджет не учитывает 18-24 месяца постоянной работы и 15-20% от capex на operating costs ежегодно, проект не доживёт до возврата инвестиций.

Reference architecture

Минимальный набор компонентов выглядит так. Event collector принимает изменения от core и CRM в реальном времени. API gateway даёт стабильный публичный интерфейс. Customer profile service хранит композитный профиль. Decision engine применяет правила и принимает решения. Channel orchestrator отправляет в нужный канал — push, SMS, email, app. Reconciliation сверяет вклады разных систем. Observability показывает где задержки. Audit log фиксирует все решения и действия.

Это минимум. На реальной программе компонентов может быть больше — campaign manager, offer catalog, consent service, fraud detector — но эти семь обязательны.

Что может сделать SamaraliSoft

BSS/OSS Around-Core Architecture Blueprint — это не «нарисуем диаграмму». Это сравнительный анализ трёх вариантов модернизации с конкретной экономикой каждого, target architecture с пятью-семью обязательными компонентами адаптированными к ситуации оператора, оценка реалистичности замены core (не всегда негативная — иногда замена правильное решение), и roadmap первых 18 месяцев с измеримыми checkpoint. Решение что и когда делать остаётся за оператором, наша задача — снять иллюзии и дать выбор основанный на фактах.

Внутренние ссылки

• /insights/telecom-after-connectivity/ — где оператор ищет рост в 2026-2035
• /cases/telecom-subscriber-360/ — реальный кейс around-core архитектуры
• /architecture/telecom-event-driven-architecture/ — события как фундамент
• /decisions/telecom-choose-bss-modernization/ — как выбрать стратегию модернизации

Источники

• Digital Government Portal — состояние digital infrastructure UZ
• Министерство цифровых технологий — телеком-сегмент
• UzTelecom — пользовательский интерфейс abonent self-service