За последние годы регулирование для мобильных и фиксированных операторов связи перестало быть внешним юридическим контуром и превратилось в движущую силу изменений ИТ-ландшафта. Законы и требования больше не «учитываются в договоре» — они встраиваются в CRM, биллинг, личные кабинеты и процессы поддержки. Для операторов это означает, что регуляторика стала такой же частью архитектуры, как тарификация или управление абонентами.
Как именно регуляторика меняет ИТ-архитектуру и какие принципы помогают операторам проходить изменения в законодательстве без сбоев? Разобрались вместе с Максимом Сысоевым, исполнительным директором российского разработчика BSS/OSS-решений «Форвард Телеком».
Как регуляторика проникает в ИТ-системы
Раньше многие требования воспринимались как отдельный контур: коммерческая деятельность, ИТ-системы и обязательные процедуры для соответствия законодательству существовали параллельно. Сегодня эта граница постепенно стирается. Регуляторика влияет на структуру клиентских данных, договоры, активацию услуг, блокировки, отчетность, антифрод-механизмы, интеграции с госсистемами и логику контакт-центра.
В мобильном сегменте изменения видны наиболее отчетливо. За последние годы появились требования к идентификации абонентов, лимитам на количество номеров (по Федеральному закону № 303-ФЗ не более 20 номеров на гражданина РФ, до 10 — на иностранца), проверке достоверности сведений и обмену данными с государственными информационными системами (Федеральный закон № 41-ФЗ о ГИС по противодействию ИТ-правонарушениям).
Для абонента новое требование выглядит как изменение правил обслуживания. Для оператора, скорее, как изменение ядра операционной модели. Теперь регуляторную норму нужно не только принять к сведению, а провести сквозь CRM, биллинг, систему управления услугами, личный кабинет, контакт-центр, интеграции, отчетность и журналы аудита. Одно законодательное изменение может затронуть десятки процессов:
- подключение и переоформление,
- смену владельца номера,
- временную блокировку и восстановление доступа,
- проверку лимитов,
- уведомления и обработку спорных обращений.
Все чаще у операторов и цифровых сервисов работа на соответствие требованиям занимает не меньше ресурсов, чем прямые задачи развития бизнеса. Это не значит, что бизнесу сложнее расти, скорее, что развитие теперь происходит в другой среде. Теперь нельзя отдельно строить продуктовую линейку и отдельно «догонять» регулирование.
Если архитектура не готова к частым изменениям, каждая новая норма превращается в отдельный срочный проект — с ручными обходами, доработками и рисками для сроков.
КИИ и импортонезависимость — требования к ИТ-ландшафту
Отдельный блок — критическая информационная инфраструктура (КИИ). Закон № 187-ФЗ вводит требования к субъектам и значимым объектам КИИ. Для операторов это означает, что технологический ландшафт должен быть не только функциональным, но и проверяемым. Например, должно быть управление доступами, журналирование, сегментация, контроль изменений и понятное распределение ответственности между заказчиком и поставщиком.
Параллельно усиливается логика импортонезависимости. Постановление Правительства № 1875 установило меры национального режима при закупках для государственных и муниципальных нужд. Для операторов это вопрос технологической стратегии — насколько систему можно сопровождать внутри страны, как быстро она адаптируется под новые требования, есть ли у поставщика компетенции для промышленного внедрения и сопровождения.
4 практических принципа для устойчивой архитектуры
Регуляторные изменения требуют от оператора не точечных доработок, а адаптивности ИТ-ландшафта. Чтобы проходить изменения без режима постоянных аварийных доработок, необходима системная модель. Первыми базовыми пунктами для реализации такого подхода могут быть следующими.
1. Постоянный контур управления изменениями
Юридическая или комплаенс-функция интерпретирует норму, а ИБ- и ИТ-архитектура, продукт и эксплуатация переводят ее в карту влияния на системы и процессы.
2. Вынос изменяемых правил в настройки
Лимиты, проверки, статусы, правила активации и блокировки — все, что может меняться, должно жить в справочниках, параметрах и бизнес-правилах, а не в коде. Иначе каждый новый закон требует отдельной доработки.
3. Тестовый контур и регрессионные сценарии
Заранее подготовленный набор сценариев для типовых операций: подключение, переоформление, смена владельца, блокировка, восстановление, проверка лимитов.
4. Журналирование и аудит «для объяснения»
Система должна хранить данные так, чтобы через месяц или год можно было точно ответить, на основании каких правил, данных и полномочий было выполнено действие. Аудит «для объяснения» — инструмент снятия рисков для самого оператора.
Новая роль билинга
Один из способов по реализации системной модели для устойчивости ИТ-архитектуры может быть биллинговая платформа. Ее функционал сводится не только к начислениям и счетам. Для современного оператора BSS/OSS — это операционный каркас, через который проходят:
- клиенты, договоры и продукты,
- услуги, параметры доступа и ограничения,
- статусы, тарификация и события потребления,
- финансовый результат.
Когда меняется законодательство, первым делом адаптируют именно этот каркас. Какие данные и где хранить, где и как выполнять проверки, кто имеет право изменить статус, какое событие отправлять во внешнюю систему — данный функционал также может входить в функционал биллинговых платформ.
Таким образом, влияние регуляторики на операторов сегодня не сводится к дополнительной отчетности или проверкам. Она меняет архитектурную повестку: системы должны быть не только функциональными, но и адаптивными. Задача ближайших лет для рынка связи — научиться развивать продукты, удерживать качество сервиса и одновременно постоянно перестраиваться под новые правила.