Рассинхронизация между системами
У телеком-оператора автоматизировано почти все: биллинг, CRM, 1С, личный кабинет, мобильное приложение, платежи, поддержка. Но чем больше появляется партнерских цифровых сервисов — IPTV, видеонаблюдение, умные домофоны, приложения, — тем сложнее становится весь контур оказания услуги.
В какой-то момент оператор сталкивается с неприятными ситуациями: у абонента положительный баланс, но сервис не работает; услуга входит в тариф, но не активировалась на партнерской платформе; объект есть в биллинге, но не сопоставлен с системой партнера. Или наоборот — услуга уже должна быть заблокирована, но продолжает предоставляться. Такие сценарии возникают именно из-за рассинхронизации между системами.
Я столкнулась с этой проблемой, когда занималась развитием продуктовой линейки на базе умного домофона. Параллельно нашему основному биллингу существовала партнерская платформа со своей моделью данных, объектами и услугами.
На схеме интеграция выглядела просто. На практике быстро выяснилось, что один и тот же объект разные системы понимают совершенно по-разному.
Для нас стандартный объект — дом. В домофонии оперируют подъездом. Дальше появляются квартира, трубка, оборудование, камеры, мобильное приложение и доступные конкретному абоненту сервисы.
Отдельная история — адреса. В интерфейсе сотрудник видит привычный адрес, но внутри одной системы он хранится под с одним address_id, в другой — под другим. Где-то используется ФИАС, где-то исторически мог остаться КЛАДР или другой справочник. Даже одинаковые ФИО в двух системах еще не означают, что системы понимают: перед ними один и тот же абонент.
Пока все связи настроены правильно, мы с клиентом этого не замечаем. Но стоит порваться одному звену — и проблема проявляется не в этом месте, а дальше по цепочке.
В нашем случае путь выглядел примерно так:
адрес в биллинге → идентификатор адреса → объект партнерской платформы → квартира → подъезд → набор доступных услуг → услуга абонента → тариф → фактический доступ к сервису.
Нарушение связей на любом этапе проявлялось как некорректная регистрация абонента или неправильный набор услуг.
Почему такие ошибки трудно искать
В сложной интеграции редко можно открыть одну таблицу и сразу увидеть причину.
До появления нормального доступа к данным расследование превращалось в длинную цепочку: нужно объяснить аналитику или специалисту биллинговой группы, какие сущности сопоставить, из каких систем взять информацию, какие статусы считать ошибкой, какие исключения убрать. Затем получить выгрузку, проверить ее и нередко понять, что нужен другой срез.
При этом владелец продукта хорошо понимает бизнес-логику услуги, а аналитик — структуру таблиц и технические ограничения. Если между этими двумя мирами нет общего языка, задача быстро обрастает локальными выгрузками и ручными проверками.
Именно здесь для меня неожиданно раскрылся DWH.
Мы привыкли воспринимать хранилище данных как основу для отчетности и BI-дашбордов. В нашем случае оно стало прежде всего инструментом расследования.
В одном подготовленном слое данных появилась возможность сопоставлять сущности из разных систем и искать расхождения. Мы начали собирать витрины, которые показывали, например, что объект существует в биллинге, но не связан с партнерской платформой; адрес заполнен не полностью; услуга в тарифе не соответствует набору сервисов на объекте; абонент зарегистрирован, но получил не все доступные ему услуги.
Важнее не найти ошибку, а заметить, что она появилась снова
Один раз выгрузить список проблемных абонентов и исправить его недостаточно.
Меняются тарифы, состав услуг и правила подключения. Появляются новые объекты и партнерские схемы. Через некоторое время расхождения начинают накапливаться снова.
Поэтому следующим шагом стали регулярные индикаторы.
Вместо сценария:
"Поступила жалоба — ищем, что сломалось у конкретного абонента" появляется другой:
"Количество объектов с определенным типом рассинхронизации начало расти — ищем причину процесса".
Именно здесь DWH начинает влиять уже не только на отчетность, но и на качество самой услуги. Для телекома, хранилище — это не только место, из которого руководитель получает график по выручке или абонентской базе. Это еще и способ увидеть сложный процесс целиком.
Когда продукт работает одновременно на пересечении биллинга, CRM, ERP, партнерских платформ и клиентских приложений, полностью исключить ошибки синхронизации практически невозможно.
Поэтому главный вопрос не в том, возникнет ли когда-нибудь рассинхронизация. Главный вопрос — кто обнаружит ее первым: сам оператор или недовольный абонент.
Если компания умеет быстро увидеть расхождение, оценить количество затронутых клиентов и найти место, где рвется цепочка, DWH становится уже не системой отчетности, а полноценным инструментом управления качеством цифровых услуг
Об авторе
- Войдите или зарегистрируйтесь, чтобы оставлять комментарии
