CC BY
4Электронный журнал «Труды МАИ». Выпуск № 37
www.mai.ru/science/trudy/
УДК 007.051
Средства развития и инструменты разработки автоматизированной расчетной системы (АСР).
Аржененко А.Ю., Байраковский С.А., Вестяк В.А.
Аннотация
Уже сейчас такие сервисы как продажа авиабилетов, авиаперевозка грузов являются неотъемлемой частью БС. Целью данной статьи является исследование средств развития и инструментов разработки современной биллинговой системы (БС), предоставляющей подобные сервисы, определение ее архитектуры, проведение сравнительного анализа существующих продуктов с целью выявления оптимальных механизмов разработки современных сервисов, предоставляемых БС. Ключевые слова
Автоматизированная расчетная система; биллинговая система; база данных; расчеты.
В России первые предшественники биллинговых систем появились в клиринговой палате для взаиморасчетов расчетов с авиаперевозчиками.
Современная биллинговая система должна отвечать растущим потребностям заказчиков и ставить абонента во главу угла бизнеса оператора. Оптимальной или «идеальной» биллинговой системы в природе не существует. Она должна быть гибкой, масштабируемой, легко взаимодействовать с уже имеющимися системами различных производителей, ее внедрение должно достаточно быстро окупаться.
На наш взгляд, рынок биллинговых систем в России находится на начальном этапе роста и имеет огромный потенциал и перспективы. Законы рынка требуют от производителей биллинговых систем все большей функциональности и гибкости решений. Одна из проблем заключается в том, что система пишется под запросы конкретного
оператора, учитывает особенности именно его бизнеса. Впоследствии компания-разработчик такого биллинга существует лишь за счет сопровождения своего продукта у данного оператора. Биллинг, написанный «под заказчика», тиражировать невозможно. Именно так исторически сложилось в России: крупнейшие отечественные биллинговые системы не тиражируются, а разработчик становится заложником своего продукта. Он едва успевает модифицировать систему под новые потребности оператора, не имея сил и возможностей на создание ее новых версий. В итоге - система неминуемо устаревает, и оператор вынужден менять ее на новый продукт.
По некоторым данным, в России установлено свыше 100 тыс. терминалов, причем 90% из них работают по агентской схеме, а 40-55% терминалов принадлежит индивидуальным предпринимателям. Наиболее известные: сеть объединенной системы моментальных платежей (ЗАО "ОСМП"), работающая под брендом "Киви" (62% терминалов), на втором месте - киоски e-port (15%), на третьем - CyberPlat (8%);
• системы, построенные на базе сети банкоматов. Такие системы есть у "Сбербанка", "ТрансКредитБанка", "Райффайзенбанка" и др. Любой клиент банка -владелец банковской карты - имеет возможность совершить оплату необходимых сервисов (мобильная связь, доступ в Интернет) в любом банкомате своей сети;
• системы для самостоятельного осуществления платежей через Интернет (WebMoney, CyberPlat, кабинеты удаленного обслуживания клиентов банков) или с помощью мобильного телефона (SMS и WAP-сервисы банков и независимых компаний, например e-port). Пользователь имеет возможность занести на свой счет некую сумму, а затем потратить ее на оплату сервисов;
• системы для оплаты сервисов на рабочем месте агентов поставщика услуг (Windows-терминалы) или в кассах розничных сетей (POS-терминалы). Пользователь передает необходимую сумму агенту или кассиру, а оплата производится непосредственно в его присутствии;
• платежи с помощью карт моментальной оплаты (платежи по ваучерам). Пользователь услуг покупает карту определенного номинала стоимости, которая имеет защитный слой, скрывающий специальный код. При необходимости оплаты клиент совершает звонок по телефону компании и с помощью системы интерактивных голосовых меню (IVR - Interactive Voice Response) указывает идентификатор лицевого счета, номер карты и код.
Современная автоматизированная система расчетов, должна обладать рядом преимуществ, которые в первую очередь должны заключаются в дополнительных сервисах, предоставляемых клиентам. В качестве дополнительных сервисов можно предложить реализовать на терминале «Доплату», например, клиент оплачивает ЖКХ, а оставшиеся внесенные средства может положить на свой телефонный номер, выбрав, нужного оператора, либо, реализовать «Возврат средств», если клиент захочет получить назад неистраченную внесенную сумму. Возможно предоставление услуги ведения единого счета клиента на стороне БС, для упрощения оплаты услуг различных операторов сотовой связи и интернет (но только по желанию заказчика), предоставление нестандартных сервисов по оказанию услуг (бронирование и продажа железнодорожных и авиабилетов, предоставление сервисов по оплате авиаперевозок, как следствие требуется разработка универсального механизма по добавлению новых провайдеров в БС.
В частности сам терминал самообслуживания может выступать в качестве информационного киоска. Например, предоставление информации о рейсах из аэропортов различных авиационных компаний, навигационная информация в рамках конкретного здания или даже города.
Однако в свете развития технологий и сфер применения можно выделить еще несколько задач:
• поддержка Web и WAP интерфейсов, позволяющих абоненту самому получать информацию и управлять своими услугами;
• поддержка GPRS;
• обеспечение работы с дилерской сетью оператора связи - поддержка продаж подключений через дилеров;
• поддержка функций автоинформирования клиентов о состоянии их балансов и о предстоящем отключении услуг;
• максимальная "персонификация" отношений оператора связи и его клиента; А также алгоритмов обслуживания клиентов, группируемых оператором связи по произвольному признаку.
Все эти сервисы направлены в первую очередь на повышение лояльности клиента. Хоть и звучит это довольно логично, большинство известных систем не реализуют вышеуказанные возможности на данный момент, а возможно, это не представляется допустимым. Немаловажны и средства, подходы к реализации тех или иных возможностей, зачастую бывает так, что система, написанная под «конкретного» оператора, становится
громоздкой (сточки зрения реализации) и попросту непригодна для дальнейшего развития. Именно эту проблему мы разберем в этой статье.
Биллинговая система по своей природе является сложным большим программным образованием и предъявляет тяжелые требования к аппаратной части. Система, разработанная под управлением СУБД Oracle 10/11j, будет наиболее рациональным решением. Таким образом, можно сразу решить одну из главных проблем - безопасности передачи данных. Безопасность работы обеспечивается в основном средствами Oracle, т.е. используются встроенные средства разграничения полномочий доступа, а работа в технологии Intranet базируется только на выделенных каналах, либо цифровых сотовых каналах.
Биллинговую систему можно разделить на две большие подсистемы, которые являются основными - биллинг (процесс формирования ежемесячных счетов) и тарификация. Остальные модули носят вспомогательный характер и обслуживают основные процессы. Система обязана работать непрерывно 24 часа в сутки, семь дней в неделю, 365 дней в году, но не должна предполагать круглосуточного наблюдения оператора. Непосредственное участие оператора есть только днем. Тарификация идет непрерывно, то есть практически в режиме реального времени, с той частотой, с которой коммутатор позволяет получать данные. Т.е. как только клиент совершил операцию, система ее обрабатывает и тут же пересчитывает его баланс (в случае наличия личного кабинета).
Подсистема «биллинг» включает в себя несколько отдельных модулей. Прежде всего, это «терминальный софт», приложение, установленное на функциональном киоске, осуществляющее взаимодействие между конечным пользователем и системой. Далее можно выделить набор приложений, необходимых для диагностики оборудования функционального киоска (чековый принтер, картридер(Сагё Reader), пинпад(Рт Pad) и др.). Такие приложения должны работать в автономном режиме и передавать всю статистическую информацию основной системе для последующего анализа (Например, многие люди сталкиваются с такой ситуацией, когда при оплате услуг оператора они не получают квитанции, т. к. лента в чековом принтере закончилась, однако их никто не предупреждает об этом).
При разработке наиболее ответственных рабочих мест, таких как «терминальный софт» необходимо уделять особое внимание быстродействию, т. к. сама конфигурация программного обеспечения на терминалах не предполагает использование приложений с высокими системными требованиями. Зачастую, большинство разработчиков в качестве основного языка программирования используют Visual C++/Delphi, возможно, это является
одной из основных ошибок, т. к. впоследствии оказывается, что терминальный интерфейс должен изменяться в зависимости от того какой оператор в данный момент оплачивается, возможно потребуется изменять сам стиль интерфейса, в зависимости от требований заказчика. В этом случае гораздо «выгоднее» как для разработчика, так и для конечного пользования будет использование технологии XAML(eXtensible Application Markup Language) - расширяемый язык разметки приложений. С помощью XAML описывается, прежде всего, пользовательский интерфейс. Логика приложения по-прежнему управляется процедурным кодом (С#, VB и т. д.). XAML может использоваться как для браузер-базированных приложений, так и для локальных настольных приложений. Таким образом, появляется возможность разделить логику приложения на две части: настройки интерфейса терминала будут конфигурироваться на отдельном рабочем месте системного администратора, в соответствии с конфигурационными файлами на терминале будет выстраиваться конечный, гибкий, легко изменяемый, интерфейс пользователя. Несомненно, технология XAML гораздо более «богаче» по своим функциональным возможностям, чем обычные WIN32-приложения.
Подсистема «тарификации» содержит в себе несколько рабочих мест, обеспечивающих контроль работы и проведение взаиморасчетов между операторами и владельцами БС (формирование ежедневных, ежемесячных, ежеквартальных отчетов). Следует заметить, что все рабочие места, относящиеся к подсистеме тарификации, могут быть реализованы в Intranet технологии через Web-сервер. В качестве Web-сервера может выступать IIS (Internet Information Services) и как следствие операционная система, на которой будут развернуты приложения - Windows XP/2007. Передача данных между приложениями и сервисом может осуществляться посредством протокола SSL (Secure Sockets Layer, криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером). Таким образом, рождается первое административное приложение, необходимое для нормального функционирования системы -«Центр сертификации БС». Данный модуль обеспечивает полный контроль прав на уровне пользователей системы (администраторов, операционистов, обычных клиентов). При выборе типов сертификатов, в первую очередь надо обращать внимание на открытый формат и высокую надежность, например, использовать сертификаты P12 (Personal Information Exchange File).
Изначально, еще на этапе проектирования БС необходимо задуматься о мультиязычности продукта. Это немаловажный момент, позволяющий, впоследствии предоставлять более широкий спектр услуг.
Например, это необходимо, если вы планируете использовать в вашей БС подпрограммы, предоставляющие различную справочную информацию по расписаниям рейсов в аэропортах или железнодорожных вокзалах.
Таким образом, все надписи на функциональном киоске, которые видит конечный пользователь, должны иметь возможность переводиться на различные языки и храниться в базе в особом формате. Следовательно, необходимо написать приложение, позволяющее быстро и удобно редактировать все надписи на терминале, переводить их на другие языки.
Отличительной особенностью «грамотно спроектированной» биллинговой системы является возможность задавать гибко-настраиваемые комиссии по каждому провайдеру, а также в разрезе дилера (владельца системы). Ниже приведем основные настройки комиссий, которые должны быть реализованы в современной БС: На уровне провайдера:
• максимально допустимый процент дополнительной комиссии дилера
• минимальная сумма допустимой комиссии дилера
• процент, выплачиваемый банку с каждой транзакции
• возмещение от провайдера
• процент, выплачиваемый БС-мой с каждой транзакции На уровне дилера в разрезе провайдеров:
• дополнительная комиссия дилера по провайдеру
• минимальная сумма комиссии
• максимально допустимая комиссия
• максимально допустимое значение минимальной комиссии
• при работе с некоторыми операторами, такими как Билайн(ВееНпе), может потребоваться: транзакционный доход дилера при разрешенной/запрещенной дополнительной комиссии)
Одной из важнейших особенностей Б.С. должна быть возможность формирования различных реестров транзакций, которые, по желанию или по регламенту необходимо направлять в сторону провайдера. Возможность формировать отчеты как дилерские, так и процессинговые. Должна быть возможность заводить новые объекты в системе и в тоже
время возможность контролировать старые, при необходимости блокировать их, вести по каждому платежу претензионную работу, если это потребуется. Необходимо организовать сервис по возврату остатка средств клиенту, если это потребуется. Все вышеперечисленные особенности можно поместить в одно приложение, разграничив права доступа операторам, работающим с ним. Настройка комиссий, а также заведение объектов системы (провайдеры, сети, дилеры и т д.) можно объединить в одно административное приложение «Back Office», помимо заведения объектов к возможностям данного модуля следует отнести формирование реестров транзакций, формирование отчетности.
Немаловажной особенностью функционального киоска должна быть возможность быстрой смены нового логотипа того или иного провайдера, а также возможность удобной смены меню на терминале, возможность передвинуть провайдеров между собой, в соответствии с договоренностью между крупнейшими сотовыми операторами. Следовательно, должно появиться приложение, в котором можно создавать схемы меню, логотипы провайдеров на терминале, а также шаблоны чеков, которые можно по нажатию на одну кнопку обновить на множестве терминалов.
Как писалось ранее, отличительной особенностью Б. С. является быстрое и понятное заведение нестандартных провайдеров, где от клиента требуется ввести помимо, привычного номера телефона, номера счетчиков (для оплаты ЖКХ), либо номер счета (для входа на страницу своего личного кабинета или пополнения счета электронной валюты) для таких целей должен быть предусмотрен механизм сценариев. Терминал в соответствии со сценарием по конкретному провайдеру отображает конечный интерфейс, которым пользуется клиент. В качестве нестандартного провайдера могут выступать различные информационные подпрограммы, целью которых является предоставление справочной информации, например, в авиапромышленности, отображение на терминале как расписания рейсов авиакомпаний для частных лиц, так и отображения информации по авиаперевозкам различных грузов.
В данной статье был подробно расписан механизм создания автоматизированной системы расчетов, приведен пример архитектуры системы на уровне СУБД, а также обозначены основные подсистемы и их модули, работа основных модулей подробно разобрана на уровне средств реализации, предложены наиболее интересные из них.
Подводя итоги можно сказать, что на настоящий момент рассмотренная архитектура построения БС нашла свое применение. Биллинговые системы с подобной архитектурой
успешно заняли свое место в сфере телефонных сетей фиксированной связи, предоставления услуг в качестве информационного киоска (расписание рейсов различных авиакомпаний ), так же повсеместное распространение они получили в сфере автоматизации расчета услуг коммунального хозяйства: водоканала, энергосетей и т.п. Связано это в первую очередь с тем, что требования к скорости обработки исходной информации не велики, а структура хранения данных схожа с организационной схемой самих предприятий. Таким образом, БС с такой архитектурой развиваются за счет охвата все новых и новых сфер (таких как авиационная промышленность). При этом развития в направлении предоставления новых услуг и интеграции со смежными областями практически нет.
Библиографический список.
1. Большова Г. Минуты любят счет // Сети. 1999. № 10.
2. Coutier P. Charging Forwards// Mobile Communications International. 2003. Nov.
3. Голомшток Л.В. Биллинговые системы для мобильной связи.//Технологии и средства связи. 2003. № 6.
4. Ляхов А.Ю. VoIP - дополнительные услуги и сервисы на последней миле//ИнформКурьерСвязь. 2003. № 6.
5. Faynberg I., Gabuzda L., Hui-Lan Lu. Converged Network and Services. - N.Y.: John Wiley&Sons, 2000.
6. Компания «Восточный ветер» обзорная статья о перспективах развитии биллинговых систем. // http://www.amobile.ru/billing/development.htm
Сведения об авторах
Аржененко Александр Юрьевич, профессор, доктор физико-математических наук Московский Авиационный Институт, (государственный технический
университет), мобильный: 8 (903) 769-08-27, домашний: 497-94-03
Байраковский Станислав Антонович, аспирант, Московский Авиационный Институт, (государственный технический университет),мобильный: 8 (906) 757-81-13, домашний: 31397-31, E-mail: stanislav@rucard.net
Вестяк Владимир Анатольевич, заведующий кафедрой, кандидат физико-математических наук, доцент, Московский Авиационный Институт, (государственный технический университет) , E-mail: v.a.vestyak@mail.ru
