Сота — оптимизация корпоративного парка SIM
Сервис управления корпоративным парком SIM: считает по каждому номеру, какой тариф выгоднее при его реальном потреблении, ловит молчащие номера и платные подписки, а экономию подтверждает фактом по счёту, а не прогнозом. Работает на боевом контракте оператора: 149 SIM, 52 подразделения, семь месяцев истории биллинга.
Задача клиента
Рекомендация по каждому номеру: кому урезать, кому добавить, кого отключить
Профиль потребления p95 за 6 месяцев, а не срез за один
Движок берёт помесячные снимки потребления по минутам, трафику и SMS за окно до полугода и строит профиль по 95-му перцентилю, а не по среднему. Дальше среди тарифов каталога ищется минимум ожидаемой стоимости с учётом абонентской платы и сверхлимита. Тариф без покрытия профиля просто отбрасывается, поэтому урезание не оборачивается дорогим перерасходом. Голосовая линейка и IoT никогда не смешиваются. Смена предлагается только если выигрыш выше порога, иначе номер честно помечается «оставить».
Обзор: потенциал отдельно, факт отдельно
Две главные цифры никогда не смешиваются. Слева потенциал, то есть сколько можно освободить, если применить все рекомендации. Рядом факт, то есть сколько уже подтверждено счётом после применённых смен. Ниже сигнальные карточки: не графики ради графиков, а конкретные поводы что-то сделать сегодня.
Рекомендации: кому, что и почему
Каждая строка это готовое решение с обоснованием, а не намёк «посмотрите тут». Видно текущий и предлагаемый тариф, экономию в месяц, уверенность и профиль потребления по 95-му перцентилю, на котором построен расчёт. Из 149 номеров подавляющее большинство помечено «оставить»: сервис не выдумывает работу там, где менять нечего.
Экономия считается фактом по счёту, а не прогнозом
План против измеренного результата, включая изменения вне сервиса
У каждой применённой смены тарифа есть плановая экономия и измеренная: сервис возвращается к номеру через несколько расчётных периодов и сравнивает прогноз с фактом по биллингу. Отдельная механика ловит изменения, сделанные мимо сервиса, напрямую в личном кабинете оператора или через сторонний сервис: суточная синхронизация видит расхождение тарифа с базой и заводит событие экономии с пометкой источника. Точность прогноза при этом считается только по собственным сменам, чтобы метрика оставалась честной.
Экономия: план против факта по счёту
У каждой смены есть плановая экономия и измеренная: сервис возвращается к номеру через несколько расчётных периодов и сверяет прогноз с биллингом. Смены, сделанные мимо сервиса, в личном кабинете оператора или через сторонний сервис, тоже попадают в зачёт, но с отдельной пометкой. Точность прогноза при этом считается только по собственным сменам, иначе метрика перестала бы что-либо значить.
Аномалии и платные услуги: то, что вручную не находят
Всплески трафика, первый роуминг, регулярные не тарифные списания
Потребление номера сравнивается с его же историей, а не с общей нормой по парку. Всплеск минут в десятки раз, впервые появившийся роуминг, аномальный трафик — всё это поднимается в отдельный раздел с описанием отклонения. Параллельно разбираются регулярные не тарифные начисления: платные подписки и услуги сводятся по номерам с оценкой ежемесячной суммы. Это тот слой расходов, который при ручном разборе счёта обычно не находят вообще.
Что нашлось в парке за период
Номер сравнивается со своей же историей, а не со средним по парку: у монтажника и у кладовщика нормы разные, общий порог поймал бы либо всё, либо ничего. Отдельно разбираются регулярные не тарифные списания: платные услуги и подписки сводятся по номерам с оценкой суммы в месяц. Это тот слой расходов, который при ручном разборе счёта обычно не находят вообще.
Заявка, согласование и применение смены прямо в контуре оператора
Двойной контроль, симуляция «что если» и полный журнал действий
Из рекомендации создаётся заявка, которая проходит согласование и уходит в API оператора на исполнение со сверкой статуса. Все действия, меняющие состояние, пишутся в журнал с перечнем изменений. До применения работает симуляция: можно прогнать сценарий по выборке номеров и увидеть результат до того, как что-то изменится в парке. Ролевая модель закрывает опасные операции, а деактивация пользователя мгновенно обрывает его сессии.
Симуляция и путь заявки до оператора
Сначала сценарий прогоняется на выборке и показывает, что будет с абонплатой и риском сверхлимита, если применить рекомендации. Только потом создаётся заявка: согласование, отправка в API оператора, сверка статуса и, уже после подтверждения, измерение фактической экономии. Каждый шаг пишется в журнал, поэтому по любому номеру видно, кто и когда что изменил.
12 рабочих экранов
От обзора парка до журнала действий
Архитектура
Бэкенд: FastAPI
Python, 58 эндпоинтов, ролевая модель и аудит
PostgreSQL
парк, помесячные снимки потребления, история биллинга
Движок рекомендаций
чистая тестируемая логика подбора тарифа, вне слоя API
Интеграция с оператором
20+ методов API: парк, счётчики, тарифы, смена тарифа
Разбор отчётов из почты
детализация приходит файлом на email и разбирается конвейером
Периодические задачи
синхронизация, матрица тарифов, backfill биллинга, бэкап
