Как правильно пишется биллинговая система

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

Ведь это прямая дорога к собственному процветанию.

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

Биллинговая система – это единая программная платформа для поддержания в актуальном состоянии данных обо всех аспектах взаимодействия между оператором и абонентами.

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

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

Подробнее о чудо-системе – в статье.

Биллинговые системы: основные понятия

Английское слово «bill» можно перевести как «счет» (другие переводы: вексель, банкнота). «Billing» переводится выражением «выписывание счета».

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

Биллинговая система (БС) — это бухгалтерская система, программное обеспечение, иными словами — «софт», разработанный специально для операторов.

Каких операторов?

• Телекоммуникационных. Т. е. речь не идет лишь об операторах сотовой связи. БС используются также операторами обычной (стационарной, проводной) связи. В малых офисах, например, можно вести биллинг телефонии (анализировать: кто звонил, когда, сколько длился разговор).
• IP-телефония — другая область применения БС.
• А интернет-провайдеры? Они тоже используют БС, например, для формирования счетов, учета трафика. Любая БС создается на основе определенной системы управления базами данных (СУБД).

Большинство БС в мире создавалось на основе СУБД Oracle. Среди других СУБД можно выделить Sybase и Informix как рассчитанные на большие объемы информации. А вот названия некоторых биллинговых систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Стоит упомянуть, что под БС может подразумеваться и аппаратное обеспечение, участвующие в организации биллинга.

Терминология

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

Существуют несколько названий биллинговой системы:

1. АСР — автоматизированная система расчетов;
2. ИБС — информационная биллинговая система.

Одним из важных качеств БС является ее гибкость, то есть способность приспосабливаться к изменившимся обстоятельствам. Гибкая система адаптирована не только к сиюминутным потребностям оператора; за счет таких качеств, как настраиваемость, модульность и открытость она позволяет решать перспективные задачи. Чем больше у системы возможностей для настроек, тем лучше.

А что такое модульность? Модульный принцип построения системы — это такой принцип, при котором вся система собирается из отдельных частей (модулей), как дом собирается по кирпичикам. БС тоже состоит из таких модулей — подсистем.

БС включает в себя, например:

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

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

Тесно связано с гибкостью БС и следующее качество автоматизированных систем расчета — масштабируемость.

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

Что важно учитывать при проектировании масштабируемых систем? Необходимо использовать СУБД, рассчитанные на большие объемы данных. СУБД должна быть совместима с различными компьютерными платформами, чтобы обеспечивать поддержку многопроцессорного режима работы.

Надежность — одно из основных требований, предъявляемым к любой системе. Надежность БС определяется надежностью СУБД и технологий, используемых при разработке системы.

Далеко не последнее место занимает надежность поставщика (разработчика) прикладного программного обеспечения: время его работы на рынке и, как косвенный показатель, процент присутствия разработанных им систем на телекоммуникационном рынке. Почему показатель косвенный? А разве Microsoft Windows самая лучшая и надежная операционная система?… И при этом она занимает значительную долю рынка.

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

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

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

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

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

Постинг биллинга — фиксация результатов расчета биллинга; после расчетов результаты становятся доступными пользователям (рассылаются, печатаются).

Что может, что должна или за что отвечает БС

Вы пользуетесь услугой prepaid? Вы задумывались, как так получается, что сразу после звонка можно узнать об изменении баланса на Вашем счету? Вас обслуживают по кредитной системе? Кто подсчитывает сумму, которую Вы должны заплатить за предоставленные услуги? Все это «обязанности» биллинговой системы.

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

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

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

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

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

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

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

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

По функциональным возможностям БС можно разделить на три класса:

1. предназначенные для транснациональных операторов связи,
2. заказные национального масштаба,
3. системы среднего класса для региональных сетей.

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

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

В масштабе региона можно вполне обойтись стандартными БС. Однако и такие системы должны обладать качествами, перечисленными выше: гибкостью, масштабируемостью, надежностью.

Любая БС:

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

Но существует и стандартный набор функций, поддерживаемых практически всеми БС. В него входят:

1. операции, выполняемые на этапе предварительной обработки и анализа исходной информации, например, функция получения данных о соединениях и услугах (запросы к коммутатору);
2. операции управления сетевым оборудованием: функции активации/деактивации (блокировки/разблокировки) абонентов и команды изменения условий подписки абонентов, передаваемые непосредственно в коммутатор;
3. основные функции приложения СУБД, включающие в себя: тарификацию записей коммутатора о вызовах и услугах;
4. формирование и редактирование таблиц базы данных расчетной системы;
5. выставление счетов и их печать; кредитный контроль счетов; составление отчетов; архивацию.

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

Основные подсистемы, характерные для биллинга, это:

• подсистема предварительной обработки данных о соединениях,
• оперативное управление биллингом,
• подсистема оповещения клиентов.

Подсистема предварительной обработки данных. Это приложение:

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

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

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

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

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

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

Подсистема оповещения клиентов. Неотъемлемая часть современного биллинга — подсистема оповещения клиентов с помощью голосовых или электронных сообщений.

Информацию для рассылки уведомлений и объявлений данная подсистема берет из таблиц базы. Перечисленное деление на функциональные подсистемы не является «строгим» для всех БС. Это лишь пример «классической» АСР.

Стандарты биллинга

Чтобы обеспечить взаимопонимание между различными БС разных операторов (это, например, требуется при роуминге, были разработаны группы стандартов биллинга. Основных международных групп стандартов три.

1. В 1998 г. американский институт стандартов ANSI утвердил стандарт ANSI 124. Дальнейшим усовершенствованием и поддержкой ANSI 124 занимается ассоциация TIA.

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

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


2. В 1998 г. было опубликовано описание первого североамериканского биллингового стандарта CIBER, который в настоящее время поддерживается фирмой CIBERNET и ее комитетом CAC-IS.

Этот комитет объединяет разработчиков биллинговых систем и телекоммуникационных операторов. Главная область применения CIBER — сотовые сети стандарта AMPS.

3. Европейский (по происхождению) стандарт ТАР появился в 1992 г. Он поддерживается рабочей группой TADIG.

Большинство операторов Европы используют ТАР2, хотя существует и третья версия. С 1995 г. модификация ТАР2, известная как спецификация TD.27, или NAGTAP2, начала применяться и в США.

Источник: "ixbt.com"

Биллинговая система — это программное обеспечение для операторов

Биллинговая система — это программное обеспечение, разработанное специально для операторов (провайдеров).

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

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

Каждый сетевой пакет анализируется и подсчитывается с точностью до байта. Учет трафика четко разделяется на «внешний» и «внутренний»:

• внешний – это трафик, полученный от вышестоящего провайдера,
• внутренний – отданный абонентам.

Внешний трафик может быть детально разделен по:

1. подключениям,
2. провайдерам,
3. серверам,
4. сетям,
5. протоколам.

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

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

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

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

Абоненты могут посмотреть в своем личном кабинете:

1. состояние лицевого счета,
2. оплаты,
3. причины блокировки,
4. свое потребление трафика,
5. сетевую статистику.

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

В его состав которой входит:

• система работы по картам предоплаты,
• интерфейс работы с договорами, счетами, актами и книгой продаж.

Traffic Inspector – это расширяемая платформа. Документированный интерфейс автоматизации и встроенного веб-сервера с поддержкой современных технологий .NET и C# для генерации динамического контента позволяет легко расширять его возможности под различные задачи.

Источник: "smart-soft.ru"

Немного о биллинговых системах для провайдеров

Биллинг — английское слово «bill» переводится на русский как счет, квитанция. Billing — это процесс выписывания счета (отсюда, кстати и Billing Address на всяких ибеях и амазонах).

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

А вся та когорта бабушек из бухгалтерии, которая считает ваши мегабайты, — Биллинговая система. По-русски это называется Автоматизированная Система Расчетов АСР или еще иначе ИБС — Информационная Биллинговая Система.

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

Расплатились с фрилансером через Яндекс-деньги? У вас со счета они списались, у фрилансера появились, в историю платежей информация добавилась. Это все биллинговая система.

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

Но для нас — связистов и инженеров — несомненно, наибольший интерес представляют системы биллинга в сетях передачи данных. Это отдельный огромный пласт технологий и знаний. И, что логично, сложность зависит от масштабов сети.

Небольшая локальная сеть организации

Начнем, пожалуй, с крохотных SOHO (Small Office/Home Office). У небольших компаний тоже часто стоит вопрос подсчета трафика: кто, куда и сколько. Чтобы бухгалтеры не пересиживали на фишках, чтобы инженеры не перекачивали торренты, чтобы директор не смотрел пор… Впрочем, что директор? — ему все можно.

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

Еще пример — это внутридомовые или внутридеревенские провайдеры, которые и по сей день существуют, перепродавая трафик тем, кто сам на интернет себе не заморочился. В общем, все это сети, где в качестве шлюза или, по крайней мере NAT-сервера, выступает Unix-компьютер с iptables и, возможно, прокси-сервером.

Схема биллинга:

Здесь правят бал бесплатные микробиллинговые системы: WinRoute Spy, Squid2mysql, StarGazer Billing System, ipq_traffic. Есть и представители платных, конечно, вроде, Lingate, например. Но часто админам не хочется допиливать чужое глючное решение, и они садятся сами писать скрипты. В итоге вполне может получиться кастомизированное приложение, которое узко заточено под нужды этого админа этой фирмы.

Сети крупных предприятий или небольшие провайдеры

Вторая ступень — это провайдеры средней руки. Речь о компаниях, обслуживающих сетевые нужды холдингов, больших предприятий и операторы ШПД на основе Ethernet. Как правило, в качестве сетевого оборудования для маршрутизации трафика здесь используются полноценные аппаратные маршрутизаторы (Cisco/Huawei/HP/Juniper итд) либо, гораздо реже, высокопроизводительные сервера.

Требования к АСР здесь уже несравнимо выше:

1. Во-первых, если вы провайдер с лицензией и вообще весь такой законный, то можно использовать только сертифицированные биллинговые системы.
2. Во-вторых, АСР в таких сетях — это очень важное для бизнеса приложение (busines-critical по-буржуйски). Соответственно за его статусом нужно следить неусыпно. То есть это регулярные бэкапы, актуальные обновления. И уже маячит на горизонет вопрос аппаратного резервирования.
3. В-третьих, АСР должна:
   • хранить в БД всех клиентов с их атрибутами (счет, реквизиты, адрес, комментарии, баланс, тариф, квоты),
   • обеспечивать работу сразу нескольких операторов,
   • иметь пользовательский интерфейс для клиентов.

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

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

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

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

В случае аппаратных маршрутизаторов для сбора данных используется специальный протокол, такой, например, как NetFlow у Сisco или NetStream у Huawei. Суть его в том, что через определенные промежутки времени будут отправляться данные о трафике на указанный в настройках хост. А можно и то же самое зеркалирование.

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

То есть если у вас аплинк к провайдеру нагружен на 85 Мбит, то те же самые 85 Мбит пойдут еще и на биллинг сервер.

Зеркалирование в биллинговой системе:

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

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

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

Спецпротоколы в биллинге:

Обычно, помимо биллинга используется еще специальный анализатор, который позволяет более гибко работать с трафиком, рисовать красивые картинки и создавать годные отчеты. Для Cisco, например, есть Netflow Analyzer.

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

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

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

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

Я вынес тогда мозг всем — и ТП биллинговой системы, и старшим коллегам, и начальнику. Спрашивал даже просто у знакомых. Никто ничего сказать не мог. Тогда я стал спрашивать у коллег, что они делали в тот день (удалось установить именно тот день, когда просела статистика по некоторым абонентам).

И когда я уже было отчаялся, вдруг всплывает, что в тот день они подключали по BGP нового провайдера. Часть трафика ушла на него, через, конечно же, другой интерфейс, который они не догадались настроить для передачи данных netflow. Две команды, и проблема, которая висела почти 2 недели, решилась.

Следует отметить, что к тому моменту уже все были на взводе, ибо биллинг — это бизнес критикал. И если вдруг кто-то придет с проверкой (у нас же сертифицированная АРС), нам зададут резонный вопрос: «Почему статистика не соответствует действительности?» — и накажут.

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

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

Самые яркие представители АРС данного класса: АСР Ideco, UTM NetUp, Bill-Master, Traffic Inspector и т.д.

Все они платные и все они сертифицированные. Но если с последним вопрос не стоит, то, возможно, вам будут интересны следующие варианты: Tmeter, NetProfile, Katrin, NeTAMS.

АСР больших и огромных провайдеров

И мы подходим к необъятным пирамидам — Автоматизированным Системам Расчета больших и огромных провайдеров, это:

• транснациональные операторы связи,
• провайдеры масштабов страны и региона.

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

Это плоскость, в которой нет места коробочным приложениям. Каждое решение здесь кастомизировано по самое «не хочу»:

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

Здесь остро встают вопросы межоператорского взаимодействия, роуминга, когда АСР должна уметь интерпретировать данные не только из своей сети, от своих устройств, но и предоставленные третьей стороной, со всеми параметрами и полями, которые важны всем втянутым операторам.

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

Основные требования к комплексам такого уровня:

• Модульность. Дополнительный функционал добавляется в рамках той же самой системы. Для этого существуют унифицированные интерфейсы, медиаторы (промежуточные узлы), среды разработки, API.
• Масштабируемость. При увеличении нагрузки не нужно менять программную составляющую, а необходимо лишь увеличивать аппаратную мощность.
• Резервирование, высокая устойчивость к сбоям. АСР работают на базе кластеров или в режиме Hot/Backup, когда резервный сервер подхватывает все сервисы в случае падения активного. Все данные находятся в хранилищах в RAID.
• Время реакции. АСР должен в разумное время принять решение о действиях над абонентом — заблокировать, ограничить скорость или сервисы, или наоборот дать больше квот и возможностей. При медленной реакции, провайдер рискует либо своими деньгами, либо удовлетворением клиента.

Решения в виде пропуска всего трафика через сервер или netflow тут никак не годятся. Это же десятки, а то и сотни гигабит. Нет, друзья, тут другой подход. Есть такое понятие, как CDR. Расшифровывается это как Call Detail Record.

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

Несмотря на название, сейчас этот термин используется в более широком смысле. CDR сейчас генерируются не только АТС, SGSN и прочим оборудованием голосовой связи, но и устройствами пакетной передачи: GGSN, DPI, маршрутизаторы и прочее.

К примеру, вот ниже типичная мобильная сеть с DPI и биллинговой системой:

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

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

Один из минусов CDR — невозможность через них управлять оборудованием — блокировать, снижать скорость. Для этого существуют системы OCS (Online Charging Service), которые имеют обратную связь с оборудованием, но это тема совсем другой статьи.

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

Источник: "telekomza.ru"

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

Биллинг — автоматизированная система учёта предоставленных услуг, их тарификации и выставления счетов для оплаты. В телекоммуникации биллинг официально именуется «Автоматизированная Система Расчётов» (АСР).

Общие моменты:

1. У каждого пользователя имеется денежный счет, с которого раз в сутки в 00:00 часов списываются средства, согласно выбранным тарифам если аккаунт не заблокирован.
2. Если на счете 0 рублей, то ничего не списывается, счет в «минус» не уходит, интернет не включается. Для включения надо пополнить счет.
3. Если на счете сумма меньше выбранного тарифа (например: на счете 5 рублей, а услуга стоит 9 рублей в сутки), эта сумма остается у вас на счету. Интернет работать не будет, поскольку этой суммы недостаточно для оплаты авансом услуг за следующие сутки.
4. Если на счете сумма больше выбранного тарифа (например: на счете 50 рублей, а услуга стоит 30 рублей в сутки) то сумма тарифа (30 рублей) спишется в полночь, интернет будет работать.

Пример:

• Вы положили на счет 50 рублей в 23:00 часа. У вас стоит тариф 512.
• При включении услуги у вас сразу спишется 9 рублей, за предоставление услуги за текущие сутки.
• Далее в 00:00 часов спишется еще 9 рублей за следующие сутки. Таким образом, уже в 01:00 у вас на счете будет 32 рубля.

Чтобы избежать этих моментов:

1. Пополняйте счет раз в месяц, умножив количество суток в месяце на тариф.
2. Пополняйте счет сразу после 00:00 часов или рано утром.

Система не делает перерасчет по часам.

ПОМНИТЕ! При включении VPN система сразу списывает деньги за текущие сутки!

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

Источник: "vneha.ru"

Принципы разработки биллинговой системы

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

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

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

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

Итак, постараемся подумать над тем, как создать биллинг на базе Linux и open source ПО.

Задачи

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

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

Кстати, не стоит путать аутентификацию и авторизацию — это разные понятия:

1. Аутентификация — процедура идентификации пользователя (обычно сводящаяся к проверке указываемых им данных на совпадение с хранящимися в системе).
2. Авторизация — процесс принятия решения о правомерности доступа пользователя к какому-то конкретному ресурсу (например, к файлу на диске или к определенной услуге связи).

Схема системы

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

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

Структура биллинговой системы ISP:

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

Услуги могут быть разными (например — VPN-доступ, dial-up пул, обычный неинкапсулированный трафик, Proxy, VoIP, etc), надо обеспечить доставку ядру системы в единообразном виде информации о том, какой тип услуги, какой абонент, в каком объеме и в какое время потребил.

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

Многоуровневая база данных

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

Логично выделить 3 уровня:

1. максимально детализированная информация без какой-либо обработки
2. классифицированная и первично агрегированная информация
3. оперативная информация

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

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

По крайней мере, при подсчете трафика через Web Proxy это решается автоматически, использование NetFlows тоже позволяет делать полную детализацию.

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

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

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

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

Технические требования

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

Основные технические требования, диктуемые бизнесом:

• гибкость,
• точность расчетов,
• устойчивость к сбоям.

Учет перспективы

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

Погрешность расчетов

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

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

Если вы перепродаете трафик, не забудьте при расчетах о том, что ваш головной ISP может под мегабайтом понимать вовсе не 1048576 байт, а, например, 1000000, что в результате дает почти 5% расхождения. Дополнительные проблемы могут составлять направления — некоторые головные провайдеры выставляют счета за входящий трафик, некоторые — за исходящий, а в ряде случаев учитывается превышающее направление.

Время реакции системы

Принятие решения о блокировке абонента при окончании средств на его счету на практике происходит не мгновенно, этот факт тоже надо учитывать. Например, если блокировка срабатывает раз в минуту — при скорости соединения 1 Мбит/с абонент может скачать лишних 7,5 мегабайт в худшем случае.

Устойчивость к сбоям

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

Актуальность данных

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

Альтернативой может быть использование протоколов динамической маршрутизации, например — RIP, с помощью которых можно получать границы пиринговой сети (если ваш головной ISP предоставляет такую услугу).

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

Общие требования

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

Отключение абонентов

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

Тарифы

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

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

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

Кроме этого, очень желательно хранить архив тарифов для возможности восстановления счетов спустя время.

Бухгалтерия

Полезно подумать об интеграции вашего биллинга в общую бухгалтерию вашей организации, например — с 1С или еще чем-то, что у вас используется для этих целей.

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

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

Лицензирование

Если у вас 100% легальный бизнес, необходимо использовать только сертифицированные в Министерстве связи РФ решения. Проблема в том, что иногда они не доступны по цене, выбор их не богат, да и зачастую эти решения далеки от идеала. В целом, вопрос с наличием лицензии на биллинг каждый решает для себя сам.

Практический пример

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

Один из часто используемых способов простого учета трафика — использование счетчиков iptables на пограничном маршрутизаторе:

1. Плюсы такого решения — простота и гибкость, возможность разграничения типов трафика на уровне правил пакетного фильтра.
2. Минусы — придется весь трафик, который вы хотите учитывать, маршрутизировать через один PC, что, в общем-то, не сильно критично при небольшой загрузке.

В качестве коллектора в таком случае может выступать небольшой PERL-скрипт, анализирующий вывод iptables.

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

Структура цепочек правил iptables:

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

В случае использования VPN (например, для продажи трафика это одно из наиболее оптимальных решений, т.к. в сетях, построенных на дешевых хабах без возможности Port Security, идентификация пользователя по IP является крайне ненадежным решением) вполне логично интегрировать модуль авторизации клиентов в скрипты /etc/ppp/ip-up и /etc/ppp/ip-down, которые вызываются демоном pppd при подъеме и опускании ppp интерфейса (а зачастую VPN-соединения представляют собой по сути, соединения, использующие PPP как транспорт для инкапсулированного трафика).

Аналогичным образом можно организовать авторизацию для dial-up соединений.

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

По сути, этот компонент и заключает в себя основную часть бизнес-логики, т.к. именно он ответственен за финансовые расчеты.

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

Источник: "citforum.ck.ua"

Биллинг для всех, или Сокровенная суть современных биллинговых систем

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

Видимо, на то, что позволит, в первую очередь, сэкономить деньги компании и получить дополнительные преимущества. Что это может быть?

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

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

Большой биллинг — большие возможности

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

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

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

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

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

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

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

А у вас НЕТ с собой мелочи! Только вечный спутник — мобильный телефон — сладко прикорнул на поясе… Что делать?! О, слава всем высоким технологиям! — я не умру от жажды перед автоматом с живительной влагой!

Я набираю на своем телефоне некоторый номер, написанный, например, на лицевой панели, ввожу свой пин-код — и получаю свою бутылочку «Пепси»!

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

• Во-первых, система отделяет трафик передачи данных, соответствующий описанной операции, от моей болтовни по телефону и результатов выхода в Интернет по WAP-протоколу.
• Во-вторых, производит тарификацию данной операции и выставляет счет.
• В-третьих, осуществляется повторная аутентификация меня лично как законного владельца баланса мобильного телефона.
• В-четвертых, осуществляется так называемый микроплатеж, то есть списание со счета небольшой суммы денег — мелочи, мелкой монеты, что само по себе является для современных автоматизированных платежных систем немалой технической проблемой.
• В-пятых, это все происходит в реальном масштабе времени: прежде чем разрешить списать нужную сумму, система проверяет, есть ли нужная мелочь у меня на счету.
• Я подозреваю, что есть еще и «в-шестых»: списание с моего счета некоей суммы за оказание дополнительной услуги по спасению организма от мук жажды посредством мобильной связи.

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

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

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

Обе стороны оказываются в выигрыше.

Абонент получает со стороны оператора заботливое и внимательное отношение («Дорогой Иван Иванович»! Завтра к полудню на соседнюю улицу завезут новую партию «Пепси» с ароматом горной фиалки — попробуйте!») и радостно приходит к выводу, что предлагаемый набор услуг — это именно то, чего ему так не хватало прежде.

Подходит в обеденный перерыв к торговому автомату и действительно обнаруживает не пробованную ранее «Пепси-Колу» с обещанным ароматом горной фиалки. Приобретает. Вкушает. Прислушивается к собственным ощущениям.
Хм. А ничего…

На поясе просыпается мобильник, а там — SMS: «Ну как, Иван Иваныч? Как Вам наша новинка? Понравилась «Пепси» с горной фиалкой? Может быть, скажете пару слов нашей сотруднице Маше, которая очень хочет узнать, понравился ли Вам лично новый напиток? Нажмите, пожалуйста, Yes, если согласны уделить пару минут Маше».

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

Оператор, со своей стороны, получает:

1. во-первых, довольного клиента (кто уйдет от оператора с таким настоящим индивидуальным подходом к абоненту?),
2. во-вторых, клиента, заказавшего дополнительные услуги (постоянная подписка на доставку новостей рынка прохладительных напитков).

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

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

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

Иными словами, современная биллинговая система — это средство сохранения дохода оператора.

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

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

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

Системы небольшого биллинга — это инструмент экономии

«А зачем нам нужна программа тарификации? — спрашивают руководители небольших компаний, когда им предлагают приобрести систему тарификации. — В счетах за междугородные и международные переговоры и так указана и стоимость всех звонков, и пункт вызова, и длительность разговора. При желании у оператора можно получить и более подробную информацию. Зачем заводить собственный тарификатор?»

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

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

• С точки зрения информационной безопасности предприятия, такие системы, как правило, обладают дополнительными средствами защиты от несанкционированного доступа.
• Кроме того, они являются незаменимым средством мониторинга лояльности сотрудников, отслеживая входящие и исходящие звонки сотрудников по телефонным номерам конкурирующих организаций.
• Штатные средства протоколирования всех действий пользователей и восстановления данных после сбоев сводят к минимуму возможные последствия намеренного вредительства, что, впрочем, небесполезно и при «естественных» сбоях оборудования.
• Важно, что анализ использования телефонных линий позволяет отслеживать среди сотрудников и нарушителей другого рода — любителей поговорить на личные темы за корпоративный счет.

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

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

О влиянии системы тарификации на снижение корпоративных расходов на связь имеются данные статистики, которые говорят, что простое введение учета приводит к уменьшению соответствующих расходов в среднем на 30%. Откуда появляются эти проценты?

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

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

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

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

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

Малый, но полномасштабный биллинг

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

Пример типичного субоператора — поставщик услуг связи для гостиниц и отелей.

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

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

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

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

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

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

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

Тарифицируем все

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

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

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

Для нерадивых медиков при такой системе контроля деятельности неминуемо наказание рублем (извините, долларом).

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

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

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

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

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

Источник: "i2r.ru"

Как правильно пишется слово «биллинг-система»

би́ллинг-систе́ма

би́ллинг-систе́ма, -ы

Источник: Орфографический
академический ресурс «Академос» Института русского языка им. В.В. Виноградова РАН (словарная база
2020)

Что такое биллинговая система простыми словами

Каждый раз, когда вы куда-то звоните, скачиваете страничку из Интернета, отсылаете СМС или просто смотрите телевизор, где-то, далеко от вас, работает биллинг. Для чего он нужен? Прежде всего, чтобы вести строгий учёт всем предоставленным услугам. Собранная информация первична. На её основе формируются начисления за предоставленные услуги и выставляются счета. Как правило, эта информация долго и надёжно хранится, ведь абонент, в любой момент, может потребовать подробную детализацию по сформированным начислениям, чтобы сверить её с полученными услугами. Вы, как потребитель услуг, можете посчитать функции биллинга вторичными или даже вредными, для себя лично, но подумайте вот о чём. Без биллинга весь этот бизнес просто не будет работать.

Итак, вы собрались продавать услуги — интернет-трафик, телефонию или вообще какой-то рекламный контент, не важно. Вам нужен биллинг. В любом случае, предоставленные услуги должны учитываться. Что биллинг умеет? Довольно много. Часто, собранная информация нуждается в предварительной обработке. Обычно, просто потому что её очень много. Для того, чтобы биллинг работал, собранные данные агрегируются, делаются более компактными.

Затем, в дело включается тарификатор, выполняя оценку собранных данных — перевод всего в деньги. Тарифицировать можно всё что угодно: продолжительность предоставления услуги, потребленный трафик, количество оказанных услуг. Сами тарифы могут быть очень сложными: стоимость услуги может зависеть от времени суток, различные направления в телефонии могут иметь разную стоимость, тарификация может вестись по преобладающей услуге. Кроме того, существуют различные скидки, бонусы и прочие акции, придуманные маркетинговым отделом. И всё это может меняться, едва ли не каждый день. Чтобы удержать потребителя, бизнес, а значит и тарификатор, должен быть очень гибким. Кстати, для работы самого маркетингового отдела, постоянно требуются отчеты. Всегда разные. С маркетингом не соскучишься.

Но вот, начисления сформированы. На этом всё? Конечно нет. Услуги могут предоставляться по условиям пред- или постоплаты. Если с постоплатой более-менее понятно, то с предоплатой всё гораздо сложнее. Биллинг должен контролировать состояние лицевых счетов абонентов, выполнять списания с них начислений в реальном времени и блокировать предоставление услуг, в момент исчерпания средств. Это важно, ведь может оказаться так, что за услугу предоставленную сверх имеющихся у абонента средств, платить придётся владельцу бизнеса, из своего кармана. А ещё, абонента крайне желательно предупреждать заранее об исчерпании средств и гибко управлять доступом к услугам, в зависимости от состояния его лицевого счета.

Остались сущие мелочи: сформировать счета, довести их до абонентов и получить деньги. Это просто, если абонентов немного, но, в большинстве случаев, для одной только печати счетов абонентам могут потребоваться услуги небольшой типографии. С получением денег тоже не всё гладко. Прежде всего, деньги — это строгая отчётность. Наличные должны быть проведены через кассу и фискализированы. Безналичные перечисления — это эквайринг с самыми разнообразными банками. Даже самый простой заявленный платеж требует функционирования личного кабинета. А личный кабинет — это современное web-приложение с надежной и безопасной авторизацией, например через ЕСИА. Как правило, для него разрабатываются мобильные приложения, как минимум для двух платформ: iOS и Android. И конечно, все данные по платежам должны быть переданы в бухгалтерскую систему.

Современный биллинг

Современный биллинг — это сложная, постоянно развивающаяся система, интегрированная со всеми системами предприятия: CRM — для работы с клиентами, ERP — для управления предприятием, SCADA — если речь идёт о промышленном производстве, бухгалтерией и аналитическими системами. Часто, биллинговая система интегрирована с системами управления оборудованием, предоставляющим доступ к услугам конечным потребителям. Биллинг — интеграция с банковскими системами эквайринга и Госуслугами, это личный кабинет и мобильные приложения. Биллинг — система, которая хранит и обрабатывает самые важные для бизнеса данные и делает это быстро и надежно. Если биллинг остановится, бизнес тоже перестанет работать.

• Взрослым: Skillbox, Хекслет, Eduson, XYZ, GB, Яндекс, Otus, SkillFactory.
• 8-11 класс: Умскул, Лектариум, Годограф, Знанио.
• До 7 класса: Алгоритмика, Кодланд, Реботика.
• Английский: Инглекс, Puzzle, Novakid.

Как пишется слово правильно: «биллинг», билинг» или «беллинг»?

Правила

Слово «биллинг» пишут с буквой «и» в корне и двумя буквами «л». Словарное слово употребляют в русском языке недавно. Оно пришло в речь от английского слова «billing» и повторяет его написание.

Проверке слово не подлежит, рекомендуется запомнить его орфографию.

Значение слова

«Биллинг» — выставление счетов и обработка платежей.

Примеры слова в предложениях

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