Price plan factory: как ускорить запуск тарифов без хаоса в биллинге

История одного запуска

Маркетинг придумал тариф. Концепт привлекательный, аудитория понятна, конкурент только что выпустил похожий и очевидно надо отвечать. Команда собирается, делает презентацию, ставит срок «через 6 недель в продаже».

Дальше начинается типичная история. Биллинг говорит: эту комбинацию пакетов в существующем каталоге нельзя — нужны изменения в правилах тарификации, это релиз, очередь на 8 недель. CRM говорит: нужно добавить новый тип продукта, change request, ещё 4 недели на тестирование. Дилерская система: нужны новые поля для оформления, релиз через месяц. Приложение: новая карточка, design plus dev plus QA, 5-6 недель. Финансы: новые счета учёта revenue, согласование с аудитором.

К моменту когда все согласования собрались, прошло три месяца. Конкурент уже снимает свой ответ, рынок сдвинулся, и тариф который выходит сейчас — это решение для прошлой ситуации. Маркетинг получает результат гораздо ниже ожиданий, и винит в этом «медленные системы».

Эта картина повторяется в большинстве телекомов в регионе. И проблема не в скорости отдельных команд — каждая работает в рамках своих ограничений. Проблема в том, что тариф структурно требует координации между 4-6 системами, и нет общего слоя, который умеет принимать новый продукт целиком и распространять его в эти системы автоматически.

Где именно теряется время

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

Первое — отсутствие единого определения продукта. Маркетинг описывает тариф в Word или PowerPoint. Биллинг переводит это в свои правила тарификации. CRM — в свою сущность. Приложение — в свой UI. Финансы — в свои настройки. Каждая команда переводит из текстового описания в свою конфигурацию вручную, и это и есть основной источник задержек, ошибок и расхождений.

Второе — каждая система имеет свой релиз-цикл. Биллинг релизит раз в 4-8 недель крупными пакетами. CRM — отдельным циклом. Приложение — мобильным релизом со своими сроками AppStore/Play. Если эти циклы не синхронизированы, тариф ждёт самой медленной системы.

Третье — отсутствие тест-окружения для нового тарифа до решения о запуске. Идея проходит долгий путь приготовлений до того как кто-то реально проверил, что её можно технически собрать. К моменту обнаружения «нельзя» уже потрачены недели согласований.

Что значит «product catalog» как решение

Идея product catalog в телеком-контексте простая. Должен существовать единый слой, в котором тариф определяется один раз, машинно-читаемо, со всеми атрибутами — пакеты, лимиты, правила тарификации, eligibility, период действия, цены, скидки, метаданные для UI. Этот слой — источник правды для всех потребителей: биллинг, CRM, приложение, дилерская система, финансы.

Когда маркетинг описывает новый тариф, он описывает его в catalog. Все downstream-системы получают его автоматически — через API или event stream. Биллинг загружает правила тарификации и применяет их без отдельного релиза. CRM создаёт нужную сущность. Приложение получает определение карточки через API.

Это меняет экономику запуска. Тариф проходит цикл «определили — протестировали — запустили» внутри одной системы, а не цикл «согласовали — раздали в 5 систем — собрали обратно — синхронизировали релизы».

Почему product catalog часто не строится

Несколько причин по которым организации откладывают этот проект.

Биллинг считает что catalog — это его внутренняя система. И часть catalog логики действительно сидит в биллинге. Но если catalog ограничен биллингом, остальные системы не получают определения автоматически. Полноценный catalog должен жить отдельно или быть архитектурно вынесен.

Проект catalog кажется большим — год работы, серьёзные инвестиции в архитектуру и интеграции. Совет директоров не любит большие проекты с долгим time-to-value, и проект откладывается в пользу «более срочных» инициатив.

CRM-вендор, биллинг-вендор и app-вендор каждый предлагают свой catalog. Если выбрать любой из них как hub — теряется vendor neutrality, и переход вендора (через 5-7 лет — нормальная история) становится крайне болезненным.

Каталог требует discipline в продуктовой команде — описывать тариф структурно, не в свободной форме. Это меняет навык, и команда сопротивляется.

Что включает рабочий catalog

Реальный продуктовый каталог в телекоме включает несколько слоёв.

Базовые компоненты. Минуты, гигабайты, SMS, услуги (роуминг, мессенджеры, контент). Каждый компонент имеет атрибуты — единица, объём, цена за единицу, лимиты, период.

Пакеты. Композиции компонентов с ценой за пакет, периодом действия, condition активации.

Тарифы и тарифные планы. Сборки пакетов с правилами их применения.

Eligibility rules. Кому какой тариф доступен — по сегменту, по региону, по statусу, по предыдущему тарифу.

Lifecycle rules. Что происходит при подключении, при истечении, при недостатке средств, при апгрейде.

Promo и discount правила. Временные модификации цен, conditions, периоды.

Метаданные для UI. Описание для дилера, описание для клиента в приложении, маркетинговая обёртка.

Если каждый из этих элементов существует в едином формате и распространяется в downstream — запуск нового тарифа становится конфигурационным изменением, не релизом систем.

Реалистичный roadmap построения

Каталог не строится за квартал. Реалистичный путь такой.

Месяцы 1-3. Foundation. Audit существующих определений тарифов в каждой системе. Описание target model каталога. Выбор архитектурного подхода — отдельный сервис, integrated в биллинг с external API, hybrid.

Месяцы 4-9. Build core catalog. Сервис каталога. Интеграция с биллингом по правилам тарификации. Интеграция с CRM по сущностям продукта.

Месяцы 10-15. Распространение downstream. Интеграция с приложением, дилерской системой. Финансовые сущности.

Месяцы 16-18. Migration существующих тарифов в каталог. Это болезненный шаг — много исторических тарифов с особенностями.

Месяцы 19-24. Operating model. Команда product catalog как отдельная функция. Discipline описания новых тарифов. Деkomission старых каналов согласования.

К двум годам у оператора рабочий каталог. Time-to-launch для нового тарифа — не три месяца, а 2-3 недели в среднем, для простых случаев — дни.

Когда не стоит начинать catalog проект

Если организация в острой фазе перестройки биллинга или CRM, добавление catalog проекта overburdens roadmap. Сначала core stabilization, потом catalog.

Если product team нет вообще как функции (тарифы придумываются маркетингом и сразу идут в реализацию), сначала нужно создать product owner функцию, потом catalog.

Если RFP под catalog не может определить кто owner — биллинг, IT или product, проект застрянет в политической борьбе.

Если выбран vendor-specific catalog без реального assessment, через 3-5 лет начинается миграция, и инвестиция обнуляется.

Если совет директоров не готов выделить 18-24 месячный invest period, catalog проект скатится в скорого quick win, который не решит проблему.

Что обсудить на committee

Сколько в среднем времени проходит от утверждения concept нового тарифа до его доступности в продаже? Если ответ затруднён или больше 2 месяцев — catalog проект имеет ROI.

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

Кто product owner каталога как сущности? Если ответа нет — функция не существует.

Какова страновая стратегия по vendor catalog vs neutral catalog? Это влияет на 5-7 летний горизонт.

Готова ли организация на 18-24 месячную перестройку без видимого quick win в первые 6 месяцев? Без этой готовности catalog умрёт в фазе foundation.

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

Product Catalog Architecture — это анализ текущего состояния (где живут определения тарифов сейчас, какие задержки и потери), target model каталога с архитектурными trade-offs, выбор build/buy/integrate стратегии, roadmap миграции, и pilot на одном tariff product line в течение 90-120 дней.

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

• /architecture/telecom-around-core-architecture/ — слой вокруг BSS/OSS
• /insights/telecom-subscriber-intelligence-operating-model/ — operating model
• /insights/telecom-arpu-bundles-devices/ — где растёт ARPU
• /insights/telecom-growth-after-connectivity/ — рост за пределами connectivity

Источники

• Министерство цифровых технологий — телеком инфраструктура УЗ
• Digital Government Portal — internet usage UZ
• UzDaily — рынок телекома
• MNP.UZ — портабельность номера