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

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

Какие модули кому нужны будут? Без модуля абонентских плат - никуда. Берем его, максмальная цена за бесконечное количество лицензий (бесконечное начинается с 10000 лицензий) - ~100тр.
А теперь смотрим чем мы занимаемся? Оператору КТВ по сути больше ничего не нужно. Провайдеру еще бы и модуль работы с сетью. Это или IPN или DialUP - и тот и другой максимально стоят тоже порядка 100тр.
Модуль телефонии - один из самых дорогих. Порядка 240тр.
Остальные модули - voiceip, модуль цифрового телевидения - по-моему не так популярны, их рассматривать не будем. Если интересно - можно посчитать на сайте.

Техподдержка, комьюнити

Спорный вопрос по техподдержке. Она платная. При покупке лицензии предлагается заключить контракт на техподдержку и приобрести пакет обращений. За 25тр можно получить 50 обращений на год. За 9тр - 15 обращений, тоже на год. Много это или мало? Мы использовали за год - 5 обращений. Сообщения об ошибках за обращения не засчитываются, но для их сообщения все равно нужен пакет хоть с одним обращением.

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

Что и приводит нас к вопросу о комьюнити и вики-базе. Сообщество мне очень понравилось. На форуме можно найти помощи практически по любому вопросу. В последнее время и ко мне в аську начали с вопросами обращаться, с радостью подсказываю, если знаю что и как.

Производительность и факапы

Официальные данные представлены на соответствующей странице сайта - bgbilling.ru/program/speed.shtml . В целом им можно верить. АП списываются довольно шустро. Радиус(мы используем модуль DiapUP для доступа к сети) держит нагрузку при одновременной авторизации 1000-1500пользователей (пропадаение света в районе, а потом включение) вполне нормально. Радиус же занимается обсчетом нетфлоу статистики. Справляется с потоком от 6 цисок с гигабитом трафика на каждой.

Если не считать факапов вызванных своими кривыми руками, то был один довольно неприятный факап 1 января 2010 года. На каждый месяц автоматически создаются новые таблицы с балансом. Из-за какой то недоработки в логике в 2010 году новые таблицы не создались. Поэтому в момент списания АП у всех был 0 на счету. Благо БД очень хорошо документирована и есть функции групповых операций - это удалось очень быстро устранить (до того как большая часть абонентов отошла от похмелья и полезла в интернет).

Запуск, перенос существующих баз

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

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

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

Заключение, сравнение с другими системами

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

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

PS если появились какие-то вопросы - задавайте, постараюсь ответить.

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

понятие биллинговых систем

Системы, вычисляющие стоимость услуг связи для каждого клиента и хранящие информацию обо всех тарифах и прочих стоимостных характеристиках, которые используются телекоммуникационными операторами для выставления счетов абонентам и взаиморасчетов с другими поставщиками услуг, носят название биллинговых, а цикл выполняемых операций сокращенно именуется биллингом. Следует сразу подчеркнуть: такие системы создаются не только на основе требований заказчиков. Существует ряд международных документов МСЭ, регламентирующих их основные функции и способы реализации этих функций. Например, документы серий E230, E260 и E1001 посвящены техническим аспектам расчета длительности соединения, регистрации вызовов при различных типах связи и определению оплачиваемой длительности связи абонентов. Описания основных принципов тарификации услуг мобильной связи и сценариев соединений приведены в рекомендациях серий D103, D110 и D93.

Указанные требования необходимо выполнять при сертификации любой биллинговой системы. Во всем остальном - в выборе СУБД, приложений и способов организации информационных хранилищ - разработчик имеет полную свободу действий. Как ни удивительно, несмотря на широкое предложение на рынке различных СУБД и систем хранения данных, значительная часть промышленных биллинговых систем в мире (примерно 9 из 10 продуктов) создавалась на основе СУБД Oracle. Объясняется ли это «монополизмом» данного продукта или высокими показателями его исполнительного механизма - однозначного ответа нет, но таковы факты. Кстати, у большинства крупнейших российских операторов сотовой и проводной связи (в том числе у «Ростелекома») установлены биллинговые системы на базе именно этой СУБД.

структура и функции

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

Очевидно, что в такой системе должны храниться не только нормативы, тарифы и информация об услугах, но и данные о клиентах, заключенных контрактах с абонентами и сторонними поставщиками услуг связи (если сеть данного оператора связана с другими), а также о стоимости передачи информации по разным каналам и направлениям. Кроме того, любая расчетная система немыслима без «истории» платежей и выставленных счетов всех клиентов, поскольку только эти сведения позволяют организовать контроль за оплатой и автоматизировать так называемую активацию/деактивацию абонентов. Чем мощнее исполнительный механизм СУБД, тем более масштабной и многофункциональной будет биллинговая система, построенная на ее основе.

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

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

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

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

Любая биллинговая система - это не «коробочный продукт»: каждая из них создается и настраивается на бизнес-процесс определенного оператора связи, имеет собственный набор функций, соответствующий технологическому циклу предоставления услуг, и может работать с конкретным сетевым оборудованием, поставляющим ей информацию о вызовах и соединениях. Тем не менее существует «стандартный» набор функций, поддерживаемых почти всеми биллинговыми системами. В него входят операции, выполняемые на этапе предварительной обработки и анализа исходной информации, операции управления сетевым оборудованием, основные функции обычного приложения СУБД, а нередко - и функции электронной почты для автоматического информирования абонентов.

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

Тарификацию записей коммутатора о вызовах и услугах;

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

Генерацию счетов и их печать;

Кредитный контроль счетов;

Генерацию отчетов;

Архивацию.

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

«Классическая» биллинговая система состоит из следующих функциональных подсистем: предварительной обработки данных о соединениях, оперативного управления биллингом, оповещения клиентов, продаж, маркетинга, обслуживания, администрирования, генерации отчетов, генерации счетов, архивации, складского и бухгалтерского учета. По сути, все подсистемы, кроме первых трех, аналогичны приложениям для работы с клиентами, которые применяются в обычных банковских системах (с точки зрения СУБД, клиент банка отличается от абонента сети лишь используемыми для получения его балансового счета таблицами, алгоритмами их заполнения и значениями ячеек таких таблиц). Поэтому, не останавливаясь подробно на их функциях, рассмотрим только подсистемы, характерные для биллинга: предварительной обработки данных о соединениях, оперативного управления биллингом и оповещения клиентов.

подсистема предварительной обработки данных

Это приложение является наиболее сложным с точки зрения как самих алгоритмов обработки, так и их реализации, поскольку именно оно анализирует исходную информацию о соединении, определяет класс предоставляемой услуги и параметры трафика - направление вызова, источник, зоны взаиморасчетов и условия роуминга. В состав данной подсистемы входит декодер исходной информации о соединениях (например, о вызовах типа CDR (Call Detail Record) или AMA (Absolute Mail Address), который извлекает данные из соответствующего файла, формируемого сетевыми коммутаторами, и обеспечивает трансляцию маршрута CDR или AMA в тарифный маршрут с учетом установленных в системе направлений и зон соединения (как внутри страны, так и международных).

Одна из сложнейших процедур этой подсистемы - поддержка роуминга. И дело даже не в необходимости применения множества таблиц для расчетов, а в том, что требуется конвертировать роуминговые записи всевозможных форматов от разных коммутаторов (с учетом различных стандартов передачи информации в канале связи) и разных биллинговых систем в тот формат записи, который используется в конкретной системе. Неудивительно, что производители сетевого оборудования и операторы связи (особенно сотовой) проявляют немалую активность в разработке биллинговых стандартов для роуминга. Сейчас наиболее распространены три стандарта, которые применяются главным образом в сетях подвижной связи. Один из них представляет собой «симбиоз» ANSI 124 и NSDP-B&S (Non-Signaling Data Protocol for Billing and Settlement) и регламентирует параметры биллинга при обмене информацией между коммутаторами различных моделей и разных производителей. Два других ориентированы на определенные стандарты сотовой связи: CIBER (Celluar Intercarrier Billing Exchange Roamer Record) - на AMPS, а семейство спецификаций TAP (Transfer Account Procedure) - на GSM. Биллинговый стандарт определяет структуру файла для обмена данными между операторами связи. В нем указывается число полей в записях файла, содержатся описания и допустимые значения этих полей. Наряду с записями о вызовах и услугах в спецификации предусмотрены поля для сумм начислений и налогов, а также для специфических характеристик вызовов, соединений или услуг (поля детализации). Несмотря на различия используемых стандартов их структуры весьма схожи, и все они используют записи фиксированной длины, поэтому между полями разных файлов можно установить некоторое соответствие (так, абонент в файле стандарта CIBER идентифицируется полем MIN, а согласно спецификации ТАР - полями IMSI и MSISDN). Можно соотнести также поля, идентифицирующие абонентское оборудование, компании-операторы, которые являются отправителями, получателями или передают информацию транзитом, поля кодов смещения времени и абсолютного времени соединения и некоторые другие.

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

подсистема оперативного управления биллингом

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

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

подсистема оповещения клиентов

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

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

стандарты взаимопонимания

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

Начало было положено в 1984 г., когда образовалась ассоциация CTIA (Celluar Telecommunications Industry Associaton), одной из задач которой стало создание стандартов записей и процедур для обмена роуминговой информацией компаний-партнеров. В 1998 г. ее комитет опубликовал описание первого североамериканского биллингового стандарта CIBER, который в настоящее время поддерживается фирмой CIBERNET и ее комитетом CAC-IS (CIBERNET Advisory Committee for Industry Standarts). Этот комитет объединяет разработчиков биллинговых систем и телекоммуникационных операторов. Главная область применения CIBER - сотовые сети стандарта AMPS. Наиболее распространенная, вторая, версия стандарта (CIBER 2.0) определяет, что файл для биллинга должен состоять из записей фиксированной длины 14 типов (по два типа для заголовков и окончаний, десять - для записей детализации).

В 1990 г. рабочая группа CTIA приступила к разработке стандарта обмена биллинговой информацией между всеми коммутаторами, участвующими в реализации вызова, - DMH (Data Message Handler). Предполагалось, что обмен будет происходить в режиме псевдореального времени, но основная сложность заключалась в обеспечении «взаимопонимания» коммутаторов разных типов, производимых разными компаниями. Через восемь лет, в 1998 г., американский институт стандартов ANSI утвердил стандарт под номером 124. Дальнейшим усовершенствованием и поддержкой ANSI 124 занимается ассоциация TIA (Telecommunication Industry Association).

После этого компания CIBERNET создала рабочую группу для определения спецификаций бизнес-процессов при передаче сообщений в стандарте ANSI 124, которые получили название NSDP-B&S. Данные спецификации устанавливают однозначное соответствие между бизнес-процессами телекоммуникационных операторов и информацией, передаваемой при обмене данными между коммутаторами по стандарту ANSI 124.

Европейский (по происхождению) стандарт ТАР появился в 1992 г. Он поддерживается рабочей группой TADIG (Transferred Account Data Interchange Group), учрежденной ассоциацией операторов сотового стандарта GSM. И хотя сейчас существует уже третья версия ТАР, большинство операторов Европы используют ТАР2. С 1995 г. модификация ТАР2, известная как спецификация TD.27, или NAGTAP2 (North America GSM), начала применяться и в США, а с 1997 г. она администрируется и поддерживается рабочей группой ассоциации NAG, объединяющей операторов сетей GSM Северной Америки.

Сегодня глобальный роуминг обеспечивает и действующая спутниковая система связи Iridium. Для обмена роуминговыми расчетами (в том числе с операторами сотовой связи) в ней используется стандарт ТАР2.

критерии выбора биллинговых систем

Информация для финансового управления. Биллинговая система должна выдавать ряд выходных данных, включая такие сведения, как:

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

Типичная биллинговая система поставляется с включением в нее многих стандартных форм отчетов (число которых обычно более 200).«Продвинутая» биллинговая система должна обеспечивать возможность ее расширения в процессе эксплуатации без привлечения разработчиков.

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

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

Управление обслуживанием клиентов. Сейчас практически все телекоммуникационные компании интегрируют системы обслуживания клиентов с биллинговыми системами. Многие ожидают, что в будущем качество систем обслуживания клиентов, обусловленное появлением интегрированных систем, будет определять степень коммерческого успеха. При выборе современной телекоммуникационной биллинговой системы следует обязательно учитывать необходимость включения в нее полного комплекта средств обслуживания пользователей. Это обеспечит органичное сочетание функций продаж, маркетинга, обслуживания клиентов, биллинга и многих функций систем управления информацией в одной полностью интегрированной системе. Важно также, чтобы такая система была интегрирована настолько, насколько это необходимо и целесообразно применительно к другим бизнес-системам данной телекоммуникационной компании. По общепризнанной оценке, приобретение нового клиента обходится в десять раз дороже, чем сохранение уже существующего. Конечно, некоторый отток клиентов неизбежен. К сожалению, люди живут не вечно, а компании переживают периоды спада. Однако операторы, придерживающиеся активной политики в отношении минимизации потерь клиентов, пожинают плоды успеха. Биллинговая система может стать наиболее ценным инструментом в деле минимизации оттока клиентов. Существует определенный риск, что пользователи, которые были клиентами компании в течение, например, одного года, и у которых истекает срок действия первого контракта, могут покинуть компанию. В этом случае биллинговая система может выдать соответствующее предупреждение, скажем, за десять месяцев, чтобы был установлен необходимый контакт с такими пользователями. Если клиенты по каким-либо причинам не пользуются наилучшим из имеющихся тарифных планов, выявление этого факта и предложение сменить тарифный план могут привести к снижению оттока клиентов и повысить их лояльность по отношению к компании. Выгоды, которые определяются снижением уровня оттока клиентов и укреплением имиджа компании и достигаются за счет разъяснительной работы и других подобных действий, могут стать весьма ощутимыми за очень короткое время.

Качество работы персонала. Хорошо спроектированная биллинговая система может предоставлять достаточно богатую информацию о качестве работы персонала. Частично это может быть следствием необходимости борьбы с мошенничеством, но не менее важны и другие аспекты. Продажа оборудования и услуг могут контролироваться и поощряться; работа по обслуживанию клиентов также может являться примером положительных действий. Интеграция «сквозной» информации в рамках биллинговой системы может принести успех, измеряемый степенью прибыльности телекоммуникационной компании. Определение конкурентоспособности. Большинство телекоммуникационных компаний работает сегодня в среде, которая является, или скоро будет, конкурентной. Хорошая биллинговая система может провести грань между конкурентоспособными и неконкурентоспособными компаниями.

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

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

Гибкий биллинг. “Гибкость” – это категория качества, о которой легко заявить, но гораздо труднее достигнуть. Наилучшие современные биллинговые системы обладают широким диапазоном параметров гибкости, куда относятся тарифные планы, скидки, типы клиентов, периоды действия тарифных планов и т. д. Телекоммуникационные компании должны очень внимательно рассматривать предложения, поступающие от поставщиков биллинговых систем. Если предлагается сделанная ранее по чьему-то заказу биллинговая система, то лучший совет для небольших телекоммуникационных компаний – отказаться от нее.

Конвергентный биллинг. Многие корпоративные клиенты в течение многих лет являются абонентами широкого спектра телекоммуникационных услуг. Эти услуги могут или не могут сводиться в один счет на оплату. По мере усиления конкуренции пользователи могут получать телекоммуникационные услуги от разных поставщиков. Составной частью развития телекоммуникационной индустрии вообще и биллинговых систем в частности является возрастающая роль требования “конвергентного биллинга”. Это означает объединение нескольких типов предоставленных услуг в одном счете на оплату. Однако эта задача не является такой уж легкой для поставщиков систем, и до сих пор весьма редко удается найти действительно конвергентные биллинговые пакеты. Отдельные телекоммуникационные компании имеют сделанные на заказ системы, предназначенные специально для этой цели, но в настоящее время возрастает число интегрированных систем. Некоторые конвергентные биллинги существуют уже в течение ряда лет, но, как и в случае с другими новшествами, телекоммуникационные компании проявляют уместную осторожность и осмотрительность, оценивая достоинства недавно появившихся конвергентных биллинговых систем.

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

Обслуживание пользователя как дополнительная ценность. Многочисленные примеры из области телекоммуникаций и других сфер деятельности доказывают ценность хорошего обслуживания клиентов. Из практики наиболее успешных представителей бизнеса следует, что хорошее обслуживание клиентов является ценным вложением, а не тратой. Биллинговая система «первого класса» с правильно интегрированной функцией обслуживания клиентов принесет щедрые дивиденды. Телекоммуникационный бизнес, подобный другим сферам экономики, должен разумно использовать свои системы. Обеспечение высокого отношения числа агентов по обслуживанию клиентов к числу самих клиентов на ранних этапах обслуживания приносит свои плоды. “Избыточность персонала” в сфере обслуживания клиентов является благоразумной составляющей капиталовложений на раннем этапе развития сферы обслуживания. Интеграция функций телемаркетинга, биллинга, обслуживания клиентов, контроля миграции клиентов и т.д. с использованием общей базы данных, прикрепленной к общей системе, обеспечивает гибкость и бесконфликтность контактов с клиентами. Агенты по работе с клиентами, следящие за выражением недовольства со стороны клиентов, должны уметь торговать. Исследования показывают, что удовлетворенный клиент более восприимчив к новым предложениям по продаже оборудования и услуг, чем другие клиенты.

технология

Администрация телекоммуникационных компаний часто затрачивает достаточно много времени на обсуждение технологических вопросов. Часто ожидается, что возмездие за неправильно выбранное технологическое решение будет очень суровым. Иногда это действительно так, однако, скорость внедрения технологических изменений зачастую сглаживает воздействие принятых решений. Применительно к операторам связи фундаментальная технология заключена в телекоммуникационных системах, а не в биллинговых или административных системах. Сюда относятся не только сети, но также и офисные системы, которые, в конечном счете, обязательно связаны с работой сети. Изменение технологии телекоммуникационной сети является непростой задачей. То же можно сказать и об изменении административных систем, с той лишь разницей, что это изменение имеет другой масштаб по сравнению с преобразованием сети. Оператор связи должен тщательно оценить стоимость и объем изменений. Например, передача базы данных из одной системы в другую – задача не для слабых духом людей. Однако ее нельзя исключать из повестки дня только потому, что она чревата опасностями. Если эта задача будет правильно оценена и решена, то процесс передачи может пройти очень гладко. Соображения, высказанные в последующих параграфах, не претендуют на то, чтобы быть исчерпывающими или обязательными к исполнению. Технологические решения, относящиеся только к биллинговой системе или преследующие более широкие цели, не подчиняются каким-то универсальным правилам, которым должны подчиняться все представители бизнеса. Единственное, чем следует руководствоваться – это фундаментальное чувство целесообразности.

аппаратное обеспечение

Телекоммуникационная компания может прийти к заключению, что ее биллинговая система должна быть “аппаратно независимой”. Реальность такова, что в течение трех-пяти лет большинство предприятий бизнеса (телекоммуникационные или другие компании) не меняют своих основных поставщиков компьютерного аппаратного обеспечения. Степень независимости аппаратной части биллинговой системы должна быть оценена применительно к процессу глобальной замены оборудования, а не к его промежуточной модернизации. Современное компьютерное оборудование, поставляемое заслуживающими доверия поставщиками, отличается высокой надежностью и зачастую поразительной производительностью. Конечно, время от времени сервера могут выходить из строя, однако, выбор оборудования не должен основываться только на его надежности – здесь существует лишь небольшое поле выбора среди авторитетных компаний. Другим важным критерием выбора является оказываемая поставщиками поддержка.

операционные системы

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

базы данных

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

прикладные программы

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

mediation

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

другие технологичесике критерии

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

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

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

соответствие современным требованиям

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

Реферат слушателя ИКСИ, научный руководитель – Сергей Кунегин

Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

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

Есть 2 основных типа расчета:

Постоплата - выставление счёта за период по его итогам (postpaid)
И авансовая система (prepaid), когда деньги заносятся заранее.

Постоплата появилась исторически раньше, но предоплата оказалась удобнее для клиентов (контролируемее – чуть что не так, происходит отключение, а не выставляется большой счёт).

Постоплатная система

Когда абонент постополатной системы расчетов пользуется услугами оператора, то на коммутаторах генерятся специальные CDR (Charging Data Record) файлы. По сути, это обычные логи, в которых указан номер абонента, дата, время разговора/объем скачанного трафика и т.п. Биллинг же, в определенное время, (например, раз в сутки) подключается к коммутатору, закачивает себе CDRы, рассчитывает стоимость услуг и сохраняет всё в базе данных (обычно, Oracle). Затем в конце месяца абоненту выставляется суммарный счет.

Схема взаимодействия Postpaid платформы с ядром сети оператора.
CSN - circuit switching network; Представлена коммутаторами каналов (MSC).
PSN – packet switching network; Представлена коммутаторами пакетов и шлюзами (SGSN и GGSN соответственно).

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

Авансовая система

В случае авансовой тарификации оператору связи, помимо учета предоставленного объема услуг, требуется решать задачу отслеживания текущего счета абонента и в случае достижения нуля, информировать абонента/отключать предоставление услуги. Поэтому такие системы еще называют Online Charging System (OCS).

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

Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP

CAP (CAMEL Application Part) – протокол прикладного уровня стека SS7, реализующий интеллектуальные услуги в GSM/UMTS сетях (например, prepaid).

Место протокола в стеке . На рисунке также представлен популярный вариант с использованием технологии SIGTRAN (расширение SS7, которое позволяет использовать протоколы “семёрки” поверх IP сети).

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

Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.

Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point - то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.

INVOKE --- A1 TAG: A1h 1B LEN: 27 --- INVOKE ID --- 02 TAG: 02h INTEGER 01 LEN: 1 02 INVOKE ID: 2 === CAP === --- INVOKE --- --- OPERATION --- 02 TAG: 02h INTEGER 01 LEN: 1 23 OPERATION: 35 = applyCharging --- APPL CHARG --- 30 TAG: 30h SEQUENCE 13 LEN: 19 --- ACH BCC --- 80 TAG: 80h 0C LEN: 12 --- TDC --- A0 TAG: A0h 0A LEN: 10 --- MAX C P D --- 80 TAG: 80h 03 LEN: 3 01 19 40 MAX C P D: 4370

Это часть трейса. Видим, что по протоколу CAP послано сообщение applyCharging, максимальное время разговора (MAX CPD - Maximum Call Period Duration) равно 437,0 сек.

Продублирую картинку до ката: это пример общения по CAP протоколу. Можно оценить временные метки: платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

CAP-протокол может тарифицировать не только голосовые звонки – он так же способен тарифицировать интернет-соединения, SMS, MMS и так далее. Хотя на практике чаще всего для этих нужд применяются специально заточенные протоколы (DIAMETER/OSA).

OSA

OSA (Open Service Access) – открытый программный интерфейс разработанный консорциумом 3GPP и ETSI, часто используется для тарификации VAS-сервисов и мобильного интернета.

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:

При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.

Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение

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

Если тематика протоколов семейства AAA вам интересна, то позже я расскажу про RADIUS, DIAMETER и другие интересные вещи.

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

Имея обычную банковскую карту, я могу совершать любые покупки и оплачивать пополнять мобильный телефон и вести бизнес. И при этом не стоять в длинных очередях в кассу банка или ждать, пока мне выпишут квитанцию на оплату с пометкой в уголке. Оказалось, для меня это идеальное решение. Я взял себе его на вооружение, но нотки сомнения все-таки закрадывались в сознание. Насколько выгодно мне это? Какова вероятность ошибки при оплате электронным платежом? Силен стереотип, «что без бумажки, ты ….». Да и наслышан о разных случаях потери платежа или исчезновения денег с мобильного.

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

Хотите знать, что такое биллинг?

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

Что такое биллинг и как он работает?

Программное обеспечение для биллинг-систем разрабатывается индивидуально, под специфику заказчика. Это могут быть и многофункциональные приложения для интернет-магазина, и корпорационная разработка (вроде функционала МТС). Все происходит автоматически, под контролем программы. расчет по для каждого клиента индивидуально, согласно предоплаченному или контрактному тарифному плану - учитывается все. Любые мелочи. Ни одна секунда или килобайт трафика не останется неучтенной, все просчитывается и тарифицируется. И нередко совершенно не в пользу потребителя. Хитрости, к которым прибегают некоторые компании в сфере просто поражают, а их заработок увеличивается на порядок.

Основная задача биллинга - это перечисление денежных средств клиента на компании за предоставленные услуги. Или в обратную сторону - начисление пакетных услуг в объеме, оплаченном, согласно тарифному плану, клиентом. Все, конечно, намного сложнее, если досконально разбирать, что такое биллинг. Есть много того, что биллинг считает и контролирует, но не стоит этим забивать голову, если вы, конечно, не захотите стать разработчиком. Для этого придется изучать намного глубже всю «кухню» телекоммуникаций и связи.

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

| Отдых и увлечения | Быт | Архив | RSS

Биллинг в банковской деятельности: система расчётов, удобная для всех

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

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

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

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

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