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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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