1. Статьи
Заметки пользователей
17762
49
22.01.2016 09:20
PDF
17762
49

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

Автор: Роман Артюх

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

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

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

Зачем вообще нужен биллинг

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

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

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

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

Проблема выбора

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

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

Продуманность архитектуры

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

Вот на что следует обращать внимание при оценке архитектуры системы.

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

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

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

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

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

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

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

Используемые технологии

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

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

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


Помощь при внедрении

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

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

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

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

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

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

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

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

Поэтому при выборе биллинга нужно обязательно уточнить у разработчиков:

  • смогут ли они помочь с настройкой описанных моментов,

  • окажут ли помощь с миграцией данных из старого биллинга,

  • будет ли проводиться обучение по работе с функциями системы,

  • состоится ли общая проверка корректности работы всех ее элементов перед запуском.

 

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

Функциональность

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

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

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

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

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

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

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

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

 

Гибкость настройки

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

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

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

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

 

Наличие сертификатов

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

Соответственно, если оператор планирует работать с количеством абонентов, которое превышает 1 млн человек, а у рассматриваемого биллинга есть сертификат, в котором максимальное число составляет 500 000, то это повод задуматься об альтернативных вариантах.

Качество поддержки и наличие сообщества пользователей

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

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

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

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

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

Стоимость и гибкость ценообразования

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

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

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

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

Заключение

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

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

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



 

49 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews

Материал:

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

 

Полный текст

Saab95
Saab95

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

 

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

 

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

vop
vop

Сначала:

 

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

 

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

 

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

 

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

YuryD
YuryD

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

s.lobanov
s.lobanov

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

 

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

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

 

+1.

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

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

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

A4on.TV
A4on.TV

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

X-RaY™
X-RaY™

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

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

 

 

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

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

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

 

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