Hp ium что это

Обновлено: 06.07.2024

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

Для начала нужно учитывать, что абонентский трафик в сети телеком-оператора генерируется и поступает с разного оборудования. Это оборудование может формировать файлы с записями (файлы CDR, логи RADIUS, текст в ASCII) и работать по разным протоколам (NetFlow, SNMP, SOAP). И нужно контролировать весь этот веселый и недружный хоровод, снимать данные, обрабатывать и передавать дальше в биллинговую систему в формате, который будет предварительно стандартизован.

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

Зачем предбиллинг операторам мобильной связи?

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

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

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

Поэтому и существует дублирующая система, которая занимается проверкой данных в биллинге и данных, ушедших от предбиллинга в биллинг. Ее задача — поймать то, что ушло с оборудования, но по какой-то причине «не легло на абонента». Эту роль дублирующей и контролирующей предбиллинг системы обычно играет FMS — Fraud Management System. Конечно, ее основное предназначение — вовсе не контроль предбиллинга, а выявление мошеннических схем и, как следствие, мониторинг потерь и расхождений данных с оборудования и биллинговых данных.

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

  1. С помощью предбиллинга по SOAP получаем данные с оборудования (HSS, VLR, HLR, AUC, EIR).
  2. Преобразуем исходные RAW-данные в нужный формат.
  3. Делаем запрос в смежные системы CRM (базы данных, программные интерфейсы).
  4. Производим сверку данных.
  5. Формируем записи-исключения.
  6. Делаем запрос в систему CRM на синхронизацию данных.
  7. Итог — абонент, качающий фильм в роуминге в ЮАР, блокируется с нулевым балансом и не уходит в дикий минус.

Еще один пример использования — накопление данных и дальнейшая их обработка. Такой вариант возможен, когда у нас тысячи записей с оборудования (GGSN-SGSN, телефония): выбрасывать все эти записи в детализацию абонента — полнейшее безумие, не говоря уже о том, что мы адски нагружаем все системы таким количеством мелких данных. По этой причине подойдет следующая схема, которая разрешает проблему.

  1. Получение данных с оборудования.
  2. Агрегация данных на предбиллинге (ждем, когда соберутся все нужные записи по какому-либо условию).
  3. Отправка данных в конечный биллинг.
  4. Итог — вместо 10 тысяч записей мы отправили одну с агрегирующим значением счетчика потребленного интернет-трафика. Сделали всего один запрос к базе данных и сэкономили кучу ресурсов, включая электричество!

Это всего лишь типовые схемы работы. Формат статьи не позволяет привести примеры более сложных схем (например, Big Data), но они тоже встречаются.

Предбиллинг Hewlett-Packard Internet Usage Manager (HP IUM)

Чтобы было понятнее, как это работает и где здесь могут возникнуть проблемы, давайте возьмем систему предбиллинга Hewlett-Packard Internet Usage Manager (HP IUM, в обновленном варианте eIUM) и на ее примере посмотрим, как работает подобный софт.

Представьте большую мясорубку, в которую бросают мясо, овощи, буханки хлеба — все, что только можно. То есть на входе самые разные продукты, но на выходе все они приобретают одинаковую форму. Мы можем поменять решетку и получим на выходе другую форму, но принцип и путь обработки наших продуктов останется прежний — шнек, нож, решетка. Это и есть классическая схема предбиллинга: сбор, обработка и вывод данных. В предбиллинге IUM звенья этой цепочки называются encapsulator, aggregator и datastore.

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

Поэтому очень важно, чтобы оборудование формировало файлы-записи, которые имели бы строго определенный и установленный производителем набор и тип данных. Каждый тип оборудования — отдельный обработчик (коллектор), который работает только со своим форматом входных данных. Например, нельзя просто так взять и закинуть файл с оборудования CISCO PGW-SGW с интернет-трафиком мобильных абонентов на коллектор, который обрабатывает поток с оборудования фиксированной связи Iskratel Si3000.

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

Изначально поток разобранных данных (RAW) формируется на уровне энкапсулятора и уже здесь же может быть подвергнут преобразованиям и фильтрации. Так делается, если нужно до схемы агрегации произвести с потоком изменения, которые должны быть в дальнейшем применены ко всему потоку данных (когда он будет проходить через различные схемы агрегации).


Файлы (.cdr, .log и прочие) с записями об активности пользователей-абонентов поступают как с локальных источников, так и с удаленных (FTP, SFTP), возможны варианты работы и по другим протоколам. Разбирает файлы парсер, с помощью разных классов Java.

Так как система предбиллинга в нормальном режиме работы не предназначена для хранения истории обрабатываемых файлов (а их может быть сотни тысяч в сутки), то после обработки файл на источнике удаляется. По разным причинам файл не всегда может быть удален корректно. В результате бывает, что записи из файла обрабатываются повторно или с большим опозданием (когда удалить файл получилось). Для предотвращения таких дублей существуют механизмы защиты: проверка на дубли файлов или записей, проверка на время в записях и прочее.

Одно из самых уязвимых мест здесь — это критичность к размеру данных. Чем больше мы храним данных (в памяти, в базах данных), тем медленнее мы обрабатываем новые данные, тем больше мы потребляем ресурсов и в итоге все равно достигаем предела, после которого вынуждены удалить старые данные. Таким образом, для хранения этих метаданных обычно используются вспомогательные БД (MySQL, TimesTen, Oracle и так далее). Соответственно, получаем еще одну систему, которая влияет на работу предбиллинга с вытекающими вопросами безопасности.

Как работает предбиллинг?

Когда-то на заре подобных систем использовались языки, которые позволяли эффективно работать с регулярными выражениями, — таким, например, был Perl. Фактически почти весь предбиллинг, если не брать во внимание работу с внешними системами, — это правила разбора-преобразования строк. Естественно, лучше регулярных выражений тут ничего не найти. Постоянно растущий объем данных и повышение критичности к времени вывода новой услуги на рынок сделали применение таких систем невозможным, так как тестирование и внесение изменений занимало много времени, масштабируемость была низкой.

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

Для работы в основном используется операционная система на базе Linux или Unix, реже — Windows.

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


Слабость этой системы — ее сложность и человеческий фактор. Любое исключение провоцирует потерю данных или неправильное их формирование.

Обрабатываются данные последовательно. Если на входе у нас ошибка-исключение, которая не позволяет корректно принять и обработать данные, встает весь входной поток либо порция некорректных данных отбрасывается. Разобранный RAW-поток поступает на следующую стадию — агрегацию. Схем агрегации может быть несколько, и они изолированы друг от друга. Как если единый поток воды, поступающий в душ, пройдя через решетку лейки, разделится на разные потоки — одни толстые, другие совсем тонкие.

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

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

В задачи предбиллинга не входит (и это правильно!):

  • мониторить, поступили и доставлены ли входные-выходные данные, — этим должны заниматься отдельные системы;
  • шифровать данные на любой стадии.

Далеко не весь поток поступающих данных подвергается обработке. Обрабатываются только те данные, которые нужны для работы. Тратить время на остальные нет смысла до того момента, пока они не понадобятся. Таким образом, из RAW-потока нужно брать только то, что нужно для схем агрегации. Из RAW (текстовые файлы, результаты запросов, бинарные файлы) парсится только необходимое.

Приватность предбиллинга

Здесь у нас полный расколбас! Начнем с того, что в задачи предбиллинга не входит защита данных в принципе. Разграничение доступа к предбиллингу нужно и возможно на разных уровнях (интерфейс управления, операционная система), но если мы заставим его заниматься шифрованием данных, то сложность и время обработки настолько увеличатся, что это будет совершенно неприемлемо и непригодно для работы биллинга.

Сама конфигурация предбиллинга с набором правил, сведениях о доступах к базам данных, FTP и прочему хранится в зашифрованном виде в файловой базе данных. Если неизвестен логин-пароль для доступа в предбиллинг, то выгрузить конфигурацию не так просто.

Любое внесение изменений в логику обработки (правила) фиксируется в лог-файл конфигурации предбиллинга (кто, когда и что менял).

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

Данные, которые проходят обработку на предбиллинге, обезличены: они не содержат ФИО, адресов и паспортных данных. Поэтому даже если вы получите доступ к этой информации, то персональных данных абонента отсюда не узнать. Зато можно поймать какую-то инфу по конкретному номеру, IP либо другому идентификатору.

Имея доступ к конфигурации предбиллинга, вы получаете данные для доступа ко всем смежным системам, с которыми он работает. Как правило, доступ к ним ограничен непосредственно с сервера, на котором работает предбиллинг, но так бывает не всегда.

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

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

Позже внедрение HP IUM состоялось в центральном офисе компании МТС и семи ее филиалах на территории России. В стадии реализации находится проект в «ТамбовЭлектросвязи». Заинтересовались возможностями данной платформы и в Центральном банке РФ.

По словам Александра Горбачева, ведущего специалиста отдела эксплуатации аппаратно-программных комплексов Банка России, несколько лет назад в ЦБ начали ощущать потребность в оптимизации взаимодействия со своими филиалами. Связь осуществлялась по различным каналам с использованием всевозможных протоколов.

Кроме того, существовала проблема учета IP-трафика. Именно поэтому ЦБ решился стать пилотной зоной для внедрения платформы HP IUM. В настоящее время на ее основе создается автоматизированная система учета степени загрузки сетевых ресурсов, в том числе по конкретным потребителям. Также идет подготовка к внедрению HP IUM в пяти регионах, для чего сейчас туда доставляется серверное оборудование и производится установка программного обеспечения.

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

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

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

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

Второй уровень иерархии IUM — это слой коллекторов-корреляторов. Корреляционных слоев может быть несколько. Третий уровень иерархии IUM позволяет полученную на втором уровне информацию уплотнить с помощью коллекторов-накопителей и преобразовать в стандартные форматы XML, HTML и ряд других.

По словам Александра Павлова, менеджера по работе с корпоративными заказчиками департамента телекоммуникаций НР, в настоящий момент IUM работает на платформах Windows, HP-UX, Solaris, Linux. Основной код IUM целиком написан на Java, поэтому теоретически может работать на любой платформе, для которой имеется виртуальная Java-машина. Кроме того, выполнена интеграция IUM с программным инструментарием HP OpenView. Поэтому администраторы провайдеров могут контролировать систему предбиллинга через центральную консоль OpenView.

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

Так как платформа HP IUM находится в постоянном развитии, компания Hewlett-Packard при ее внедрении придерживается политики пилотных проектов, которые пока осуществляются для заказчиков бесплатно.

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

"Дальсвязь", лидирующий оператор на телекоммуникационном рынке Дальнего Востока России, предоставляет все виды услуг связи - местной, междугородной и международной телефонии, доступа в Интернет, передачи данных, ISDN, IP-телефонии, сотовой, транкинговой и пейджинговой связи, беспроводного радиодоступа.

Место предбиллинга в инфраструктуре оператора связи

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

Предбиллинг - обусловленная временем необходимость

Еще несколько лет назад биллинговые системы, или автоматизированные системы расчетов (АСР), большинства операторов связи имели единую, монолитную архитектуру. Они реализовывали весь цикл расчета - от получения учетной записи о предоставленной услуге до формирования счетов и отслеживания прохождения денег по счетам клиента.

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

Павел Богацкий: "Пилотный проект

показал широкие возможности HP IUM"

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

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

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

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

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

Для решения этих проблем и созданы системы предбиллинга, или Mediation System, основное назначение которых состоит в преобразовании данных, принятых от сетевых элементов, в информацию, которая может быть интерпретирована биллинговой системой и другими бизнес-системами оператора (аналитикой, CRM, системой защиты от мошенничества).

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

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

Среди известных в нашей стране систем предбиллинга можно упомянуть Fastcom Mediation, Tizona-M, HP IUM и Inter-mediat E. Одной из самых удачных реализаций систем предбиллинга является продукт IUM компании HP. В настоящее время предбиллинг на ее основе построили несколько десятков операторов связи по всему миру.

Пилотный проект предбиллинга в компании "Дальсвязь"

"Специфика интеграции систем предбиллинга в сетях различного масштаба состоит в том, что на уровне городских сетей, за исключением крупных мегаполисов, предбиллинг часто не дает очевидных преимуществ,- считает Инна Миронова, менеджер проектов компании "Открытые технологии". - А вот в региональном и федеральном масштабе работа централизованной биллинговой системы без предбиллинга сегодня практически невозможна".

В "Дальсвязь" входит семь филиалов (Приморский, Сахалинский, Хабаровский, Камчатский, Магаданский, Амурский и расположенный в Еврейской А/О), и компания обслуживает территорию, сравнимую по площади со всей Европой. Да и масштаб ее сетевых ресурсов немалый - порядка 1400 АТС и 1,2 млн. номеров монтированной емкости.

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

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

Для имеющегося у "Дальсвязи" коммутационного оборудования, в частности для АТС MT20 и SI2000, средствами HP IUM были написаны коллекторы, собирающие информацию о совершенных звонках - CDR (Call Detail Records), помимо этого осуществлен сбор и обработка данных из IP-сети в соответствии с типом трафика (корпоративный, Интернет-трафик, трафик провайдера).

"Пилотный проект показал широкие возможности HP IUM как гибкого инструмента по сбору и подготовке данных для биллинговой системы и анализу работы сети", - отметил Павел Богацкий, начальник отдела развития информационных технологий "Дальсвязи".

«Мобильные ТелеСистемы» собирается использовать систему предбиллинга корпорации Нewlett-Рackard. Соглашение на поставку программной платформы уже подписано, а перемены в биллинге первыми почувствуют московские клиенты сотовой компании.

4 ноября 2002 года Hewlett-Packard объявила о заключении соглашения на поставку системы предбиллинга HP OpenView Internet Usage Manager (HP IUM) для крупнейшей российской сотовой компании «Мобильные ТелеСистемы».

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

МТС собирается применить эту платформу для сбора, обработки и распределения данных по услугам, предоставляемым ею своим клиентам.

«Внедрение данной системы на базе решения HP IUM 4.1 позволит компании МТС оптимизировать процесс сбора информации, повысить скорость тарификации до близкой к реальному времени, а также создаст условия для централизованного учета данных об оказанных услугах на всей сети МТС», – говорит начальник службы расчетов МТС Сергей Строганов.

Однако скорость тарификации поднимется до «близкой к реальному времени» не сразу и не везде. Проект внедрения предбиллинга разбит на несколько этапов и на начальной стадии будет включать в себя развертывание пилотной системы просто для демонстрации возможностей HP IUM в московской сети МТС. Только к концу 2002 года, опираясь на полученный в столичной системе опыт, компания начнет прорабатывать решения в масштабах всей своей сотовой сети.

Повышение точности биллинга и его унификация для всей сети среди российских национальных операторов наиболее актуальна для МТС.

МТС обслуживает очень динамично развивающуюся абонентскую базу, в которой насчитывается уже более 5,7 млн абонентов, и продолжает активно вести региональную экспансию через приобретение других российских сотовых компаний. В таких условиях, когда в сети начинают использоваться самые разные системы учета услуг, а нагрузка на биллинг растет в геометрической прогрессии, без внедрения универсальной и мощной системы предбиллинга обойтись сложно.

В создании предбиллинга для МТС будет задействовано подразделение «НР консалтинг», призванное обеспечить управление проектом, обучение специалистов и техподдержку, а также «Центр разработки НР», который выделит из своих ресурсов профессионалов для оперативной доработки под задачи сотовой компании программных компонентов HP IUM.

В «Мобильных ТелеСистемах» отказываются называть даже порядок затрат на внедрение системы предбиллинга. Однако из опыта российских компаний известно, что это не дешевое удовольствие. В конкурирующем «ВымпелКоме», который решился на полную замену отечественной билинговой системы «Атлант» на зарубежную Amdocs (это масштабируемая система используется мировыми сотовыми гигантами), процесс перехода занял почти год, потребовал «очень больших денег, но был совершенно оправдан».

Биллинг может быть и конкурентным преимуществом. Перейдя на Amdocs, «Би Лайн» начал изощряться с тарифами: побайтовый учет GPRS, учет «переходящих» минут, тарификация хоть с первой, хоть со второй.

МТС же не первый раз приходится решать проблемы с биллингом. Так, в прошлом году компания произвела серьезную модернизацию используемой у себя системы CBOSS, которая на определенном этапе просто перестала поспевать в своем развитии за быстрорастущей абонентской базой.

Чтобы снять с себя подозрения в нечестном обсчете МТС до сих пор проводит акцию бесплатного предоставления счета-детализации и 1 ноября объявила о ее продлении еще на три месяца. Введение предбиллинга вопрос ставит иначе: не «закрыть проблему с биллингом», а расширить его возможности, но суть от этого не меняется – к биллингу не должно быть претензий.


Кто и как контролирует своевременность оказания медицинской помощи при сердечно-сосудистых заболеваниях


Сервис такси от Яндекс стал удобнее для незрячих


"Сельский туризм": необычный отдых в России


Как в России проходит реабилитация пациентов, перенесших COVID-19


Мир меняет свое отношение к деньгам


Каким может быть современный ноутбук


Студентам предложили создать проект о безопасности на дороге


Что нужно для реабилитации переболевших COVID-19


«Это такая попытка проверить нас». Что делают корабли США у берегов России

Самуцевич не привлекли к экстремизму

В «Ростелеком» пришли за молоком

ФБР рассекретило дочку Сталина

Два удара в сердце

Зурабов узел пенсионной системы

Вздрогнули после первой

Критическая масса экстремизма

Букашки без бумажки

Старость строгого режима

ФБР рассекретило дочку Сталина

ХАМАС уперся в столп

Безобразия в кабинете Медведева

«Израиль играет с огнем. Это будет большое кровопролитие»

Дерипаска не может подойти к «Русснефти»

На фронтах войны форматов

Microsoft сыграет, недорого возьмет

У ТНК-ВР украли буквы

Вексельберг купил швейцарские насосы

Франция теряет конкуренто­способность

«Двадцатка» бросит тень на $67 триллионов

Рынки отошли от обрыва

Самуцевич не привлекли к экстремизму

Два удара в сердце

У Ройзмана изъяли видеоархив

«Все предатели будут наказаны»

В 1962 году Аркадий и Борис Стругацкие написали «Попытку к бегству». Теперь бы это

Читайте также: