Факты по расчету

Автор: Александр Милицкий
Опубликовано в журнале "Компьютерра" №41 от 2 ноября 2004 года.

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

Время — деньги

Первые «грабли», которые подстерегают и оператора, и его абонентов, — выбор между системой с накоплением и системой реального времени. Система с накоплением обходится куда дешевле, — независимо от того, приобретать ли ее у разработчика в готовом виде или создавать самостоятельно, — и требует минимальных ресурсов. В конце каждого расчетного периода (который может быть равен суткам, месяцу или пяти минутам) такая система «засасывает» данные об услугах, потребленных абонентами, и вычисляет, насколько изменилось состояние каждого счета. Если речь идет о коммутируемом доступе, то поставщиком информации выступает система авторизации (RADIUS или TACACS); если о выделенном — маршрутизатор, через который к пользователю проходят пакеты с данными; если о телефонии — телефонная станция. Продолжительность расчетного периода определяется лишь волей оператора да возможностями имеющегося у него «железа». Например, для корпоративных клиентов, подключенных по выделенным каналам, данные можно рассчитывать раз в месяц, при выставлении счетов, — никаких сюрпризов при этом ожидать не приходится. Специализированный сервер пожужжит некоторое время, которое в этом случае критического значения не имеет, — да и выплюнет необходимые сведения, а то и сразу счет на бланке распечатает. Поскольку процедура выставления счетов обычно занимает несколько дней, для этих целей годится и не слишком мощная техника, — никто никуда особо не торопится. Корпоративные пользователи, как правило, — люди солидные, платят аккуратно, скандалов операторам не устраивают, — а для того, чтобы их расходы не вышли за рамки бюджета, используют собственные средства контроля, позволяющие отследить не в меру «прожорливых» сотрудников. Да и в случае возникновения конфликта оператор всегда может добиться погашения долга в судебном порядке. К тому же компании, использующие Интернет в своем бизнесе, не склонны доводить конфликтную ситуацию до отключения, ведь убытки, которые несет, скажем, турагентство из-за потери связи с внешним миром, обычно во много раз превышают спорные суммы, — так что куда лучше сперва оплатить выставленный счет, а потом уже разбираться. В общем, не клиент, а просто клад для провайдера.

Когда речь заходит о частных пользователях, вести себя таким же образом было бы чрезвычайно рискованным для провайдера. Ведь добиться выплаты долга физическим лицом практически невозможно. Нет, разумеется, суд примет решение в пользу оператора, — но толку-то? Ждать, пока задолженность в несколько сот долларов будет погашена за счет принудительно удерживаемых 10% от трехсотрублевой студенческой стипендии или копеечной «белой» зарплаты, — занятие малоприятное. Клиенту же, получающему свою реальную зарплату в конверте и сумевшему влезть в огромные долги перед оператором, зачастую попросту дешевле отказаться платить по счету и подключиться к кому-нибудь другому. С весьма высокой степенью вероятности его оставят в покое.

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

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

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

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

Иное дело, когда провайдер вынужден сам рассчитываться с другими операторами живыми деньгами. Например, платить «Ростелекому» за телефонное соединение с Занзибаром или вышестоящему провайдеру — за потребленный абонентом трафик. Тут уж никуда не денешься, и если абонент откажется платить, оператор, что называется, попадает на бабки.

Года три тому назад, когда профессионально построенные территориальные сети были еще в диковинку, а массовый пользователь, привыкший к дайлапным скоростям, еще не освоился с быстрыми каналами, произошла забавная история. Некий добрый папаша подарил сыну-школьнику на день рождения выделенный доступ в Интернет, оплатив подключение и абонентскую плату на три месяца вперед. Оплатил, отметим, по одному из минимальных тарифов, резонно сочтя, что сотни мегабайт в месяц для рефератов, «Яндекса» и прочих целей, связанных с учебой, за глаза хватит. Сыночек же, обрадовавшись подарку, ощутил себя великим хакером и решил на практике ознакомиться с теми уязвимостями чужих компьютеров, о которых он до сих пор лишь читал. Поставив у себя сканер портов, он ввел в качестве мишеней диапазон IP-адресов в добрые пол-Интернета и, не мелочась, указал железяке дергать жертвы за все доступные порты общим числом 65635, — после чего отправился спать, отложив знакомство с добычей на утро.

Провайдер, к которому подключился вундеркинд, только-только начал предоставлять услуги. Пользователей у него было мало, и незадачливому хакеру досталась в распоряжение практически вся полоса 10-мегабитного внешнего канала. Компьютер у него был по тем временам мощный и пакетики посылал весьма шустро. На следующий день разъяренный папаша звонит в службу поддержки, дабы узнать, почему не работает Интернет, подключенный только накануне вечером. Стали разбираться, и выяснилось, что когда биллинговая система подвела итог за минувшие сутки, обнаружила отрицательный баланс и выдала команду на блокировку доступа, юноша успел отъесть гигабайт тридцать трафика. Что стоило, в соответствии с выбранным тарифом, тысячи три долларов. Разумеется, счастливый отец отказался платить и заявил о немедленном расторжении договора. Однако смириться с потерей клиента и попросту списать задолженность провайдер тоже не мог, ибо рассчитывался с вышестоящим оператором помегабайтно. И хотя межоператорские тарифы были заметно ниже пользовательских, однако лишаться нескольких сот долларов из-за художеств юного хакера никто, конечно же, не собирался. Возникла патовая ситуация.

Как она разрешилась, не столь важно (достаточно сказать, что обе стороны остались недовольны друг другом). Важно то, что если у пользователя есть техническая возможность за короткое время потребить большой объем услуги с высокой безусловной себестоимостью, слишком большая продолжительность расчетного периода может стать источником конфликтов. И если в Москве расчет все чаще идет не за трафик, а за каналы, эта проблема не очень актуальна, то в регионах, где цены выше, а провайдеры платят «РТКомму» и «Транстелекому» за каждый гигабайт, — опасность довольно велика. Кроме того, снижение тарифов компенсируется стремительным ростом абонентской базы. С точки зрения оператора, нет большой разницы, недоплатит ему единственный пользователь за перерасход ресурса на $100 или же сто пользователей недоплатят по $1, — ущерб получится одинаковым. Поэтому общей тенденцией является уменьшение расчетного периода, которое в пределе дает системы реального времени, способные отключать абонента в тот самый момент, когда на его счету закончатся деньги. Такой биллинг позволяет не только избежать потерь, но и предложить разнообразные дополнительные сервисы вроде возможности в любую секунду проинформировать пользователя о состоянии его счета. Однако, как уже говорилось, системы реального времени не только дороже, но и требуют гораздо больших вычислительных ресурсов, что при обширной клиентуре может влететь в копеечку. В результате, если безусловная стоимость предоставляемых услуг невелика, многие крупные операторы предпочитают обходиться более дешевым в эксплуатации биллингом с приемлемым расчетным периодом. Так, пользователи погигабайтных тарифов «Стрим» знают, что раз в сутки провайдер разрывает с ними соединение, которое будет восстановлено лишь в том случае, если баланс на этот момент остается положительным. «МТУ-Интел» — довольно крупная компания, обладающая большими ресурсами, — однако при большом числе обслуживаемых пользователей и невысокой безусловной себестоимости ей проще позволить клиенту скачать немного лишнего трафика, чем постоянно отслеживать состояние баланса каждого из них.

«Унутре у ней — неонка!..»

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

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

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

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

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

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

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

«Бухгалтер, милый мой бухгалтер….»

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

С одной стороны, довольно удобно, когда по окончании очередного месяца биллинг автоматом распечатывает счета и экспортирует все необходимые сведения куда-нибудь в «1С:Бухгалтерию». Жить становится намного проще, появляется возможность изрядно сэкономить на бухгалтерских вакансиях, а ежемесячный аврал превращается в неторопливое рутинное раскладывание бумажек по конвертам. С другой же — излишняя привязка АСР к бухгалтерской системе может выйти боком. В вырожденном случае каждая операция биллинга обрастает соответствующей бухгалтерской проводкой, и любая нестандартная ситуация рискует превратиться в головную боль. К примеру, в результате аварии магистрального канала пользователи, чье соединение с модемным пулом провайдера благополучно было тарифицировано биллингом, в течение нескольких часов не имели выхода в Интернет. Руководство решает вернуть на их счета средства, которые были списаны за это время. Как, с точки зрения бухгалтерии и налогообложения, будет выглядеть «подарок» оператора в виде пары-тройки долларов на счет каждого абонента? Это мы с вами знаем, что на самом-то деле никаких долларов нет и не было, а просто клиентам компенсируются часы и минуты, которые они не смогли полноценно потратить из-за аварии. С точки же зрения бухгалтерии эти фантомные деньги вполне реальны. Точно так же, если биллинговая система глубоко интегрирована в бухгалтерию, затруднение вызовет любая операция, проведенная задним числом, — например, изменение тарифного плана.

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

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

Все выше, выше и выше…

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

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

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

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

Операторы технической поддержки и менеджеры, общаясь с клиентом, у которого возникли проблемы, разумеется, должны иметь возможность ознакомиться с текущим балансом его счета. Зачастую, когда требуется принять решение на месте, крайне полезной оказывается платежная история пользователя. Например, если тот оплатил услуги оператора через сбербанк, но платеж еще не дошел, а послать квитанцию по факсу у него нет возможности, — требуется решить, принять ли на веру его слова, и зачислить ли ему на счет так называемый обещанный платеж. Понятно, что абонент, пользующийся услугами не первый год и постоянно тратящий на них заметные деньги, будет пользоваться бо,льшим доверием, чем тот, кто только что подключился, и притом просит под честное слово положить на его счет сумму, превышающую все, что он успел до того потратить. Однако одной только платежной истории может оказаться и недостаточно, — например, при повторном общении с клиентом, который уже звонил по поводу возникшей у него проблемы. Особенно это актуально в крупных компаниях, где каждая смена состоит из десятков операторов, и попросту переключить звонок на того из них, кто уже общался с этим пользователем и в курсе его проблемы, оказывается не всегда возможным. Возникает необходимость документировать всю историю взаимоотношений с клиентом, включая его проблемы и жалобы. Неплохо было бы также, чтобы сообщения о возникающих неполадках автоматически транслировались бы дежурной смене инженеров, — а те могли бы потом внести информацию о времени устранения проблемы и ее причинах. В результате к биллингу прикручивается хотя бы примитивная CRM-система (Customer Relationship Management — «управление взаимодействием с пользователями»).

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

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

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

Выбор пути

Разрабатывать собственную биллинговую систему или же приобрести готовую? Несколько лет назад такого вопроса возникнуть попросту не могло, — рынка АСР практически не существовало, и каждый оператор был вынужден выкручиваться самостоятельно. Кстати, многие успешно продаваемые сегодня системы создавались провайдерами для собственных нужд. Впрочем, за прошедшие годы ситуация заметно изменилась, — появились сравнительно недорогие коробочные решения, и даже компании, специализирующиеся на создании биллинговых систем (самая известная из них — CBOSS; www.cboss.ru). Так что сейчас начинающий оператор имеет неплохой выбор.

Каковы достоинства и недостатки того или иного варианты? Приобретая систему стороннего производителя, вы получаете ее сразу и тотчас можете приступать к работе, — в то время как разработка, отладка и сертификация даже не очень сложной собственной АСР потребует времени.

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

Представления о том, будто разработка собственной АСР обойдется дешевле, чем приобретение коммерческой, давно устарели. Да, простейший набор скриптов может быть написан системным администратором буквально за несколько дней без отрыва от выполнения основных задач, — но его функциональности для нормального обслуживания абонентов в соответствии с современными требованиями явно недостаточно; создание же серьезной системы потребует выделять людей под это занятие. А зарплата даже одного программиста необходимой квалификации за время, требуемое на разработку чего-то серьезного, сравнима со стоимостью покупной системы. Кроме того, разработанный биллинг рано или поздно придется сертифицировать, чтобы его использование не вызвало трений с Госсвязьнадзором, коммерческие же системы сертификат уже имеют. А поскольку стоимость сертификации составляет около $5000, суммарные затраты окажутся приблизительно того же порядка, что и при покупке. Несколько лет назад, когда стоимость профессиональной коммерческой системы составляла от $30–50 тысяч, финансовый выигрыш от «наколенного» варианта мог быть довольно заметным, — но с тех пор на рынке появились гораздо более дешевые коробочные решения. Поэтому при прочих равных, если ассортимент предоставляемых услуг не содержит никакой экзотики, — удобнее и выгоднее приобрести коммерческую систему.

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

Во-вторых, нередко взгляд разработчика на принципы тарификации той или иной услуги может сильно расходиться с потребностями оператора. Например, очень легко тарифицировать выделяемое под виртуальный сервер дисковое пространство установкой дисковой квоты: пользователь получает запрошенный им объем, превысить который физически не в состоянии, — и этот объем, вручную введенный в базу, элементарно обсчитывается исходя из месячной стоимости аренды мегабайта. Если же провайдер хочет, например, чтобы абонент мог самостоятельно занять столько места, сколько ему надо, с последующим выставлением счета на соответствующую сумму, — то реализовать снятие данных и особенно их обсчет, будет намного сложнее. В самом деле: если в начале месяца файлы клиента занимали на сервере 10 Мбайт, в середине он залил туда гигабайт, который через пару дней удалил, а к концу довел объем информации до 20 Мбайт, — расчет суммы месячного платежа может оказаться весьма нетривиальным делом, и не факт, что разработчики коммерческой системы сумели предугадать все возможные всплески фантазии провайдерских маркетологов.

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

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