Перейти к содержимому
Калькуляторы

Девять важных факторов при выборе биллинга

Материал:

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

 

Полный текст

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сначала:

 

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

 

И все скатывается к:

 

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

 

Вот и думаешь, нафига управляющим компаниям поддержка софтсвичей. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В общем, масло маслянное, а вода мокрая. Статья ни о чём. Главное в АСР - сертификат соответствия. И чем дешевле, тем лучше. А уж привязывание к АСР СРМ и прочее - оно конечно полезно, но дорого.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Согласен с Saab95, что статья ни о чём, а проще говоря унылое говно. И даже согласен с тем, что потрахушки с установкой это неприкольно. Все нормальные люди подобные приложения дают (в том числе) как appliance/образ виртуалки (требующие много внешнего ПО - БД, веб-сервер и т.п.)

 

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2" и кривыми сетями, требующими для сервис-активации залезать на свитчи доступа и там что-то править в конфиге. Я вот знаю пару мест, где ничего не умеющий UTM5 успешно работает и ничего не делает кроме списания/внесения денег, rad auth и rad PoD. Всё просто до неприличия и не требует миллиона фич, которые меняют своё поведение от версии к версии (тот же самый ланбиллинг, который либо совсем не тестируют перед релизом, либо этим занимается команда макак с клавиатурами)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2"
тут не соглашусь, всё же маркетинг главнее технарей, вот например тарифы на ГИГАБИТ надо давать, и плевать на старые свичи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2" и кривыми сетями, требующими для сервис-активации залезать на свитчи доступа и там что-то править в конфиге. Я вот знаю пару мест, где ничего не умеющий UTM5 успешно работает и ничего не делает кроме списания/внесения денег, rad auth и rad PoD. Всё просто до неприличия и не требует миллиона фич, которые меняют своё поведение от версии к версии (тот же самый ланбиллинг, который либо совсем не тестируют перед релизом, либо этим занимается команда макак с клавиатурами)

 

+1.

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

Во-вторых service activation должен быть реализован стандартными протоколами (RADIUS), а не кучкой мутных скриптов, делающих 10 разных операций в 5 местах. К примеру, мы слезли с ISG + DHCPD с самодельными скриптами и еще куча всякой обвязки на модель IPoE, где все разруливается через RADIUS CoA. Ну и еще AAA через RADIUS. Схема service activation стала проста как мычание. Работать стало в разы проще.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обычная рекламная статья. Хвалим то, что есть в своем билинге и ругаем все чего нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я как раз с гидрой общаюсь на тему внедрения...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

Вот оно как..... нет я знаю один типа-биллинг где невозможно проследить историю платежей)

Старгейзер называется.

Но всерьез обсуждать его в статье для провайдеров?

 

Ощущение что автор пишет пересказ того что услышал от кого-то из технарей и понял неправильно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>Я как раз с гидрой общаюсь на тему внедрения...

а я как раз внедряю уже второй раз.

пиши если есть вопросы. помогу

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перл устаревшая технология...

Я это уже лет 10 слышу... Но что-то вот всё никак не устареет и не умрёт... ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2"
тут не соглашусь, всё же маркетинг главнее технарей, вот например тарифы на ГИГАБИТ надо давать, и плевать на старые свичи.

 

вы неправильно поняли. где я сказал, что продавать гигабит это плохо? (пусть даже не имея тех.возможности обеспечить - это на вашей совести). я лишь пытаюсь донести, что пора завязывать со всяким дерьмом типа приведи друга и получи XXX бонусных баллов, на которые потом можно "купить" ускорение интернета или 1.5 дня интернета. всё это слишком сложно/костыльно реализовывать в условиях того, что все биллинги проприетарны (ну есть конечно смешные поделия типа abills и ещё какая-то фигня, но никто же не воспринимает их всерьёз). все эти "акции" приводят к тому, что нужно постоянно платить за доработки или делать их самим костылями, которые не факт что отработают корректно и как следствие, негатив со стороны абонента

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перл устаревшая технология...

Я это уже лет 10 слышу... Но что-то вот всё никак не устареет и не умрёт... ;)

 

не, ну реально % использования Perl в новых проектах близок к нулю. мне 28 лет и почти никто из моих ровесников на Perl не пишет, люди постарше - да

 

и тут самое главное тренд(http://www.w3cook.com/programminglanguage/perl ) - Perl'ом пользуются всё меньше и меньше и скоро программисты Perl будут как сис.админы какого-нибудь AIX, они вроде бы и не нужны, но когда надо - особо и не найдешь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

они вроде бы и не нужны, но когда надо - особо и не найдешь

"Когда надо" - это новое написать или прочитать, понять, починить/поправить то что есть? Если править - то понятно, почему нет. Оно в большинстве случаев не слишком читаемо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну есть конечно смешные поделия типа abills и ещё какая-то фигня, но никто же не воспринимает их всерьёз

 

Ну да, не воспринимает. Слишком мало надо за них платить. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2"
тут не соглашусь, всё же маркетинг главнее технарей, вот например тарифы на ГИГАБИТ надо давать, и плевать на старые свичи.

 

вы неправильно поняли. где я сказал, что продавать гигабит это плохо? (пусть даже не имея тех.возможности обеспечить - это на вашей совести). я лишь пытаюсь донести, что пора завязывать со всяким дерьмом типа приведи друга и получи XXX бонусных баллов, на которые потом можно "купить" ускорение интернета или 1.5 дня интернета. всё это слишком сложно/костыльно реализовывать в условиях того, что все биллинги проприетарны (ну есть конечно смешные поделия типа abills и ещё какая-то фигня, но никто же не воспринимает их всерьёз). все эти "акции" приводят к тому, что нужно постоянно платить за доработки или делать их самим костылями, которые не факт что отработают корректно и как следствие, негатив со стороны абонента

именно что и бонусная система нужна со сложными правилами и плевать на проблемы технарей, нужно именно полтора дня!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отвечу про Perl ссылкой, которую случайно нашёл несколько дней назад...

http://habrahabr.ru/post/245659/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Куча спорных моментов :)

 

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

 

В Гидре баланс абонента не выбирается из БД, а получается вызовом stored procedure. И всё бы ничего, но, блин!

- Оно МЕДЛЕННО!

- Оно НЕУДОБНО!

- При выводе в црм-ке пары сотен абонентов с балансом, нам прямым текстом "не порекомендовали" так делать, т.к., судя по анализу быстродействия, отображение этой странички (десяток раз за день) давало одну из самых больших нагрузок на i/o в системе.

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

 

 

А в целом билинг хороший :)

Изменено пользователем Wingman

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А сами пересчеты будут происходить не часто.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"Когда надо" - это новое написать или прочитать, понять, починить/поправить то что есть? Если править - то понятно, почему нет. Оно в большинстве случаев не слишком читаемо.

 

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

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

 

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

 

В одном соглашусь - софт на перле в эксплуатации сейчас дороже остального, если нет маньяков из старой гвардии :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.