посоветуйте биллинг для 20к абонентов

[adeep 212]

ага, а когда Линус Торваль перестал заниматься линуксом то Линукс умер )

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

[VitalVas 14]

Мне биллинга с названием "АБ" хватает

[~AsmodeuS~ 34]

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

 

Где закрытая разработка ?

[NiTr0 585]

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

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

 

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

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

[~AsmodeuS~ 34]

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

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

 

вот тут в точку только ключевая фраза тут "достаточный уровень знаний"

[exnetlife 126]

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

20к на этом этапе звучит как вопрос в автосалоне - "Дайте мне машину у которой тормозной след 20м".

 

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

 

Какой биллинг вам нужен?

 

И тут начинаются наводящие вопросы типа:

- Нужно ли генерировать инвойсы или достаточно посчитать?

- Нужен ли вам Realtime или достаточно HOT-биллинга для ваших задач?

- Какой жизненный цикл у ваших абонентов сейчас? Предвидется? (припейд или постпейд).

Из этого выплывает ответ на вопрос - нужна ли вам конвергентность.

- У вас плавающий биллинговый период?

- Количество тарифов/продуктов на данный момент (это влияет на скорость и стоимость миграции абонентов)

- тут же возникает вопрос миграции абонентов, есть ли уже эти абоненты, в каком биллинге они сейчас?

 

Далее, когда определились с этим, идет капасити (только здесь говорится о количестве абонентов и суммарном трафике который нужно обрабатывать), под это дело владельцы биллингов делают HW sizing (и вы смотрите, нужно ли покупать сановский кластер или же p4 хватит по это дело). Потом идет планирование, инсталяция, ИНТЕГРАЦИЯ (вот этот пункт, как раз миграция абонентов, переделка API под вашу CRM, настройка сетевого провиженинга и прочих радостей, которые нужно оговорить ДО).

 

Вот так вот, в кратце, выглядит выбор биллинга.