Обсуждаемая реформа лицензирования операторов связи меняет не столько список формальных требований, сколько саму операционную модель рынка. Малым операторам все чаще предлагают развилку: перевести абонентов на прямое обслуживание по агентской схеме или остаться под собственным брендом на чужой инфраструктуре. И это в первую очередь вопрос не юридический, а архитектурный — вопрос готовности BSS/OSS.

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

Что именно меняется на рынке

Реформа обсуждается, но не принята — это важно зафиксировать сразу. Минцифры прорабатывает изменение лицензирования: сокращение числа типов лицензий и повышение требований к операторам, включая размер уставного капитала. По обсуждаемым сценариям часть требований может вступить в силу с 1 сентября 2026 года, при этом ранее выданные лицензии сохраняют действие еще какое-то время — называется период до начала 2028 года. Оценки последствий расходятся, но отраслевые ассоциации говорят, что новым требованиям по капиталу и собственным средствам не соответствует порядка трети игроков рынка широкополосного доступа.

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

Четыре сценария для малого оператора

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

Первый путь — остаться самостоятельным оператором и выполнять все требования самому. Это сохраняет полный контроль над бизнесом, но поднимает порог входа: капитал, отчетность, эксплуатация собственного BSS/OSS-контура. Для части игроков это подъемно, для многих — нет.

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

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

Четвертый — работать под собственным брендом на инфраструктуре партнера. Оператор сохраняет бренд, клиентский интерфейс и локальное знание рынка, а биллинг, charging, provisioning и часть регуляторных обязательств уходят более крупному игроку. По сути это white-label или MVNE-подобная модель, где партнер отдает платформу как сервис.

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

Почему «просто передать клиентов» не работает

На словах агентская или сервисная модель выглядит просто: один оператор отдает абонентов, другой их обслуживает. На практике за этим встает несколько контуров управления, которых у самостоятельного оператора раньше либо не было, либо они были тривиальны.

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

Ни один из этих вопросов не решается текстом договора. Договор фиксирует, кто кому и сколько должен; исполняет это BSS/OSS. Если контур не готов, партнерская модель вырождается в ручные сверки в таблицах, споры о начислениях и рост операционных затрат — ровно то, ради ухода от чего она и затевалась.

Что должен закрыть BSS/OSS-контур

Партнерская модель нагружает не одну систему, а связку.

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

CRM, Help Desk и Service Desk определяют, как обслуживается абонент и обращение. Ключевой момент — маршрутизация: какая заявка остается у оператора-бренда, какая уходит на платформу партнера и как склеивается единая история обращения, чтобы клиент не пересказывал проблему дважды.

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

SCD и WFM отвечают за ресурсы, оборудование, подключения и монтажи. Там, где сохраняется физический доступ и работы «в поле», нужно понимать, чьи ресурсы задействованы и как это отражается во взаиморасчетах.

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

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

Что это значит для крупного игрока

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

На практике это означает вполне конкретный набор требований к платформе: быстро подключать нового партнера без проектной доработки; изолировать данные партнеров друг от друга; держать разные тарифные политики на одной платформе; считать разные схемы комиссий и штрафов; давать партнеру прозрачный личный кабинет с начислениями и сверками; удерживать единый стандарт обслуживания независимо от бренда. И масштабироваться так, чтобы сотый партнер подключался по тому же конвейеру, что и первый. Если каждое подключение превращается в отдельный интеграционный проект, экономика партнерской сети не сходится — расходы на onboarding съедают маржу с агентского вознаграждения.

В моделях такого класса критична не отдельная система, а связность контура. Отдельный биллинг или отдельная CRM не решают задачу, если тарифы, клиентские данные, события сети, партнерские расчеты и процессы обслуживания остаются разорванными. В продуктовой линейке Forward этот контур закрывают BSS/OSS-компоненты, PRM, SCD, Billing и интеграционные модули — от регистрации и маршрутизации заявок до расчета вознаграждений, штрафов, KPI и сверок, включая личный кабинет партнера и автоматический расчет вознаграждений. Ценность здесь не в наличии отдельного модуля, а в том, что партнер, тариф, абонент и расчет живут в одном управляемом контуре.

Вывод

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

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