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

Аспект стоимости:

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

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

Выбор биллинга, это всегда компромисс между продуктами, находящимися в разных стадиях своего развития и чем мельче оператор (читай - в большинстве случаев, чем меньше у него абонентов) тем более сырой (находящийся на более ранней стадии своего развития) продукт он выбирает, и обратно, чем оператор богаче, тем более совершенное решение он может себе позволить (MTS и Foris за 143 000 000 $ первоначальных вложений). Если не брать в расчет экстремумы функции выбора :) (взять в качестве целевой аудитории оператора телефонии и услуг ШПД с абонентской базой от 5 до 50 тыс. абонентов), то именно средний оператор встанет перед непростой проблемой выбора биллингов средней же ценовой категории, охарактеризовать которую можно лишь удельной стоимостью абонента в 5 – 60 рублей за пользователя. Как правило, в этой ценовой нише присутствуют продукты уже доросшие до второй стадии своего развития и косвенными признаками (кстати, эти признаки по моему скромному мнению, можно использоваться в качестве наводящих вопросов производителю АСР при поверхностном первоначальном знакомстве с ним) таких систем являются следующие:

• от 5 лет присутствие на рынке
• от 500 пользователей продукта (операторов, применяющих продукт разработчика)
• продленный сертификат Министерства связи (назовем его так т.к. в последнее время название министерства уж слишком часто меняется), и желательно неоднократно, что автоматически означает несколько раз сменившийся номер major версии по отношению к старту продукта. Основной номер версии никто из производителей не меняет чаще, чем раз в три года – период действия одного сертификата Минсвязи, зачем тратить бессмысленно средства ради того, что бы поменять число в номере версии.

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

Аспект качества и соответствия потребностям оператора

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

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

Выбирая биллинг стоит задумываться о перспективе собственного бизнеса. Если сегодня Вы предоставляете только ШПД доступ, это вовсе не значит, что через 2-3 года Вы не станете оказывать услуги телефонии, к примеру. Поэтому введение новых услуг не должно вызывать замену биллинговой системы ибо процесс этот весьма болезненный и, как правило, сопряжен с серьезными временными потерями сотрудников. АСР должна позволять тарифицировать максимальное количество разного рода услуг.

Степень открытости разработки.

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

Выбор БД

Часто встречается заблуждение: чем «круче» используемая системой БД, тем «круче» биллинг и «круче» его разработчики. Возможности БД должны быть достаточными для удовлетворения потребностей биллинговой системы к системе хранения. Чем «круче» БД (это я про Oracle) тем на большие $$ расходов вы обрекаете себя в качестве первоначальных вложений в приобретение лицензий, регулярные лицензионные отчисления и заработные платы специалистов, которые будут эксплуатировать систему на Oracle. Чем, кстати, дальше от городов миллионников, тем в геометрической прогрессии падает вероятность найти толкового администратора такой СУБД. В частности Oracle (раз уж эта СУБД является одним из ярких примеров, которые приводят наши пользователи, задавая вопрос «А почему не «СУБД такая-то»?») стоит использовать только в том случае если логика работы биллинговой системы вынесена в БД. Если же реализация бизнес процессов зашита в АСР, то со всех точек зрения выгоднее использовать MySQL или PostgreSQL, как разработчикам, так и пользователям.

Конвергентность

Этот термин в проекции на биллинг в википедии определяется как система, способная объединить в едином расчетном комплексе, как предоплатных абонентов, так и постоплатных. Тем не менее, это не единственное свойство, которым должна обладать «гибкая» АСР. Практика внедрений нашей разработки показывает, то на рынке нет стандарта расчетов с абонентом, по которому работает оператор. У некоторых принято баланс расчетного счета «привязывать» к услуге (тогда балансов и расчетных счетов становится столько сколько услуг потребляет клиент), некоторые операторы «привязывают» расчетный счет к пользователю (тогда все услуги тарифицируются на одном расчетном счете и баланс, соответственно, один на все слуги). Наиболее гибким решением является «привязка» расчетного счета к договору. Подавляющее большинство телефонистов, к слову, (так разработчики на сленге называют операторов местной, МГ/МН телефонной связи) применяют именно такую систему расчетов. Выгода такого решения заключается в том, что помимо объединения предоплатных абонентов с постоплатными оператор волен определять самостоятельно какой набор услуг какого именно абонента должен тарифицироваться с единым расчетным счетом и, соответственно, по одному договору, а какие услуги должны быть тарифицированы индивидуально.

Телефония и агентская схема

Что, касается «телефонистов», как мы с легкой руки окрестили операторов телефонии в предыдущем абзаце, то АСР без реализации агентской схемы,  для задач тарификации телефонной связи вовсе не подойдет. Всему виной закон о связи и правила показания (которые можно найти по ссылке: Правила оказания услуг местной, внутризоновой, междугородной и международной телефонной связи, в редакции постановления правительства РФ №408 от 30.06.2005) операторов телефонной связи. В соответствии с этим документом, в большинстве, случаев операторы местной связи собирают с абонентов деньги, при этом либо выставляя счета от имени зонового или МГ/МН оператора, либо проводя взаиморасчет по соответствующему агентскому договору, выставляя счета от имени местного оператора. В любом случае в биллинге необходима поддержка и одного и другого принципа межоператорского расчета для услуг телефонии.

Система управления распределенной сетью, Inventory, SNMP управление

Наличие в АСР возможности инвентаризации активных сетевых устройств и управления ими - дань тенденции стремительного падения стоимости управляемого порта за последние 10 лет. Операторы вплотную подошли к контролю услуги на порту устройства, тем самым решая насущные проблемы контроля локальных IP потоков, а также мультисервисного контроля (раздельное управление услугами на одном и том же порту). Для этой цели уже разработаны достойные технологии, начиная от 802.1x и DHCP опции 82, до проприетарных, заложенных вендорами в свои устройства механизмов. Современной системе не достаточно скриптовых решений по управлению сетью распределенных устройств, рынок требует решать задачи их (устройств) учета, назначения абонентов в свободные порты коммутаторов, аналитики по утилизации, наличию свободной емкости, диагностики наконец (банально удобно видеть инженеру техподдержки в момент звонка абонента статус активности абонентского порта и SNMP доступность коммутаторов абонентского сегмента). Существует огромная масса систем SNMP контроля распределенной сети активного оборудования, однако, ценность наличии инвентори именно в биллинге - наличие связи порта с конкретным абонентом.

Реализация BSS BusinessSupportSystem (CRM, подсистема обработки заявок и т.п.)

Деятельность даже мелкого оператора сопряжена с наличием формализованных, обеспечивающих бизнес, процедур, которые документально оформляются в соответствии с внутренними правилами конкретного оператора. Вариативность этих процедур велика, поэтому важным качеством АСР является возможность автоматизации этих правил работы с абонентами, начиная от печати заданий на подключение монтажникам и заканчивая фиксацией общения менеджеров с абонентами по почте и телефону. Безусловно, рынок насыщен CRM/HelpDesk/BSS системами, построенными в соответствии с современными принципами, изложенными в ITIL, в том числе. Однако наличие системы поддержки бизнеса в биллинге часто может, если не заменить внедрение «тяжелой» BSS, например, на базе относительно дорогой Microsoft Dynamics CRM 4.0 (возможность интеграции с CRM также крайне необходима и желательна посредством API АСР), то хотя бы, отсрочить ее внедрение, при этом, обеспечив необходимый и достаточный набор функций. 

Масштабирование

Задача модульного расширения системы тарификации возникает, как правило, в двух случаях: территориальной распределенности обеспечивающей сети оператора и при объективном увеличении нагрузки на систему тарификации, связанную, как правило, с увеличением абонентской базы или интенсивностью потока первичных данных об оказанных услугах (одно с другим линейно связано). Система тогда безболезненно справится с ростом оператора, когда она, во-первых модульная, во-вторых у производителя разработаны «строительные блоки» размножая которые система справляется с прогрессивно растущей нагрузкой пропорционально количеству «блоков». Под «строительными блоками» в данном контексте имеется ввиду набор программно-аппаратных средств, рассчитанных на тарификацию и управление определенными услугами для определенного количества абонентов. К примеру, нашей компанией методом проб и ошибок, на примере узла связи одного из подмосковных операторов, доминирующих в масштабах города, был разработан такой «строительный блок» для услуги ШПД, оказываемой при помощи PPPOE технологии, рассчитанный на 7500 абонентов. При превышении этого кванта абонентской емкости требовалось закупать аналогичную аппаратуру и устанавливать ее в состав узла. Крайне важна умная архитектура АСР, заложенная разработчиками на этапе проектирования. А именно, поддержка всеми программными компонентами биллинга всех трех уровней возможной организационной структуры оператора – «узлы связи -  оператор (регион) – управляющая компания». В терминах АСР LANBilling, примерами таких компонент системы являются: агент, сервер, supervise платформа.  

Нагрузочная способность модулей АСР

Нельзя не обратить внимание, при выборе биллинга на качество реализации программного кода элементарных составляющих системы – модулей (агентов – коллекторов, mediation, provisioning, серверного уровней), о котором, безусловно, говорят нагрузочные испытания, которые проводят разработчики. Сам факт наличия результатов таких испытаний, как, например, для одного из агентов (http://www.lanbilling.ru/load_tests.html и http://www.lanbilling.ru/load_tests_02_2007.html) АСР говорит о том, что разработчиком проводится оптимизация кода, важность которой вряд ли стоит подчеркивать.      

В начало страницы

© Компания «Сетевые решения», 2001-2010.     Все права защищены.   программа учета трафика, биллинг, учет трафика, billing, программа учета трафика, биллинг, учет трафика, billing, программа учета трафика, биллинг, учет трафика, billing, программа учета трафика, биллинг, учет трафика, billing, программа учета трафика, биллинг, учет трафика, billing, программа учета трафика, биллинг, billing, программа учета трафика, биллинг, billing, программа учета трафика, биллинг, billing, программа учета трафика, биллинг, billing, программа учета трафика, биллинг, billing компания   ·   продукты   ·   решения   ·   статьи   ·   партнеры   ·   контакты