Личный кейс из телекома: как мы сопоставляли биллинг, 1С, адреса, услуги и партнерскую платформу, чтобы найти, где нарушается синхронизация

Когда говорят про DWH, чаще всего обсуждают управленческую отчетность, BI-дашборды, витрины данных и красивые графики для руководителей.

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

Раньше я работала менеджером проекта, а потом директором по продукту в телеком‑компании. Занималась развитием продуктовой линейки на базе умного домофона: абонентские сервисы, видеопоток, управление доступом, дополнительные услуги, интеграции с биллингом и внутренними системами.

Телеком — это среда, где почти все процессы так или иначе автоматизированы. Есть биллинг, CRM, ERP, личный кабинет, мобильное приложение, платежные системы, сайт, каналы поддержки, внутренние сервисные системы.

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

У телеком‑оператора большая часть процессов завязана на биллинг. Именно там «живет абонент», лицевой счет, тариф, услуги, состояние баланса, подключения, отключения и правила оказания сервиса.

Но вокруг основного биллинга часто появляются партнерские платформы:

— IPTV;
— видеонаблюдение;
— умные домофоны;
— сервисные приложения;
— дополнительные цифровые продукты.

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

В теории это выглядит логично.

В реальности возникает много нюансов. Начнем с того, что Фомина Мария Валерьевна в одном биллинге, не равно Фомина Мария Валерьевна в другом. Это два разных человека, до тех пор, пока ты не создашь точное сопоставление.

Операторы во фронте видят адреса в «человеческом» виде, а внутри систем они хранятся в отдельных справочниках со своим уникальным адрес_id и в лучшем случае имеют дополнительный иднетификатор из единой библиотеки ФИАС, а в худшем вы работаете с ФИАСом, а ваш партнер с КЛАДР или ГАР.

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

Если все эти сущности идеально синхронизированы — услуга работает корректно.

Если синхронизация нарушается, начинаются неприятные сценарии.

Что происходит при рассинхронизации

Самый очевидный риск — абоненту некорректно оказывается услуга.

Например:

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

Вручную такие ошибки очень сложно искать.

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

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

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

Почему обычная аналитика не помогала

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

Чтобы получить выгрузку, нужно было объяснить аналитику или сотруднику биллинговой группы, что именно нужно увидеть:

— по какой сущности нужна выборка;
— из какой системы брать данные;
— как сопоставлять адреса;
— какие услуги учитывать;
— какие статусы считать ошибкой;
— какой период анализировать;
— какие исключения убрать;
— какие объекты считать активными.

Но главная сложность была в том, что заказчик отчета и исполнитель отчета часто по‑разному понимали предметную область.

Продуктовый менеджер понимает бизнес‑логику: как должна работать услуга, какие ошибки критичны для абонента, какие сценарии уже вызывают обращения в поддержку.

Аналитик понимает структуру данных, таблицы, ключи и технические ограничения.

Если между этими двумя мирами нет общего языка, задача зависает.

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

В итоге проблема не решается системно. Она обрастает ручными проверками, локальными выгрузками и временными исправлениями.

Мой личный опыт с DWH

Переломный момент наступил, когда внутри компании появилась идея: данные должны быть доступны не только аналитикам, но и линейным руководителям, продуктовым менеджерам и владельцам процессов.

Не в смысле «пусть все ходят в боевые базы и делают что хотят».
А в смысле: есть DWH, есть подготовленные, нормализованные данные, есть понятная структура, есть возможность писать SQL‑запросы и собирать собственные витрины под управленческие задачи.

Для меня это стало переломным изменением.

Я смогла не просто поставить задачу на выгрузку, а сама начала разбираться:

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

В моем случае DWH оказался не «витриной для отчетности», а инструментом расследования.

Как мы искали ошибки

Одна из ключевых задач была связана с сопоставлением адресов и объектов.

| Адрес в биллинге → уникальный идентификатор адреса в 1С → объект в платформе домофонии → номер квартиры → диапазон квартир в подъезде → однозначная привязка к подъезд_id → потом уровень услуг →  услуга → абонент → тариф → доступ к сервису.|

Если на одном из шагов связь рвалась, дальше начинались ошибки.

Мы стали собирать витрины, которые показывали расхождения:

— объект есть в биллинге, но нет корректной связи с партнерской платформой;
 — адрес заведен, но не сопоставлен однозначно — не все поля заполнены,
 — услуга есть в тарифе, но не соответствует доступным услугам на объекте;
 — абонент зарегистрирован, но не получил корректный набор сервисов;
 — объект подключен, но часть услуг не активировалась;

Важным было не просто найти одну ошибку, а настроить регулярный контроль.

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

Почему «заказчик отчета» должен понимать SQL

Один из неожиданных выводов: никто лучше владельца процесса не понимает, какой срез данных ему нужен.

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

Когда продуктовый менеджер или руководитель умеет хотя бы на базовом уровне работать с SQL, сильно сокращается путь:

от «мне кажется, у нас проблема»
до «вот конкретная выборка, вот тип ошибки, вот масштаб, вот динамика».

Это не отменяет работу аналитиков. Наоборот, делает взаимодействие с ними качественнее.

Вместо абстрактного запроса «сделайте мне отчет по ошибкам» появляется нормальная постановка:

— какие таблицы нужны;
 — какие сущности сопоставляем;
 — какие признаки считаем ошибкой;
 — какие исключения учитываем;
 — какие показатели выводим;
 — как будем проверять результат.

Что важно при внедрении DWH

Наш опыт хорошо показал: DWH не должен быть только проектом «для руководства».

Если DWH живет только как верхнеуровневый BI‑дашборд, его ценность ограничена.

Настоящий эффект появляется, когда данные начинают использовать владельцы процессов:

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

На встречах, я часто слышу «Управление должно основываться на цифрах», но большинство компаний работают с устаревшими данными, контролируют запаздывающие метрики и зачастую данные от разных отделов по одним и тем же показателям различаются на 15–20%.

Сколько заняла работа

В моем случае сбор первой рабочей версии отчета занял около двух недель параллельно с операционной работой.

Это не была красивая финальная BI-система с идеальным интерфейсом. Это был рабочий инструмент, который позволил увидеть масштаб проблемы и начать управлять ею.

И это важный момент.

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

— собрать данные;
 — сопоставить сущности;
 — увидеть ошибки;
 — посчитать масштаб;
 — сформировать план исправлений;
 — начать отслеживать динамику.

А уже потом можно развивать полноценные дашборды, автоматические проверки, алерты и регулярные витрины.

Главный вывод

Для меня DWH — это не про «хранилище ради хранилища» и не про красивые графики.

DWH — это способ СОЗДАТЬ управляемость там, где процессы слишком сложные для ручного контроля.

Например как в телекоме, где каждый продукт живет на пересечении биллинга, CRM, ERP, партнерских платформ, приложений, личных кабинетов и сервисных команд.

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

Влюбилась в DWH и хочу передать вам свою увлеченность.