Содержание к диссертации
Введение
Глава 1. Состояние вопроса и постановка задачи 10
1.1. Терминология 10
1.2. История появления и развития биллинговых систем 10
1.3. Стандарты. Классификации. Сертификация . 13
1.4. Схема процесса и функции биллинга . 14
1.5. Требования к биллинговым системам . 18
1.6. Обзор существующих систем 21
1.7. Проблемы, возникающие при разработке и эксплуатации систем биллинга 25
1.8. Тенденции и перспективы развития . 27
1.8.1. Универсальность 27
1.8.2. Интересы югаента 28
1.8.3. Повышение масштабируемости . 28
1.8.4- Комплексные системы 29
1,8.5. «Публичный биллинг» и аренда биллинга 29
1.9. Постановка задачи 30
1.10. Выводы по главе 1 31
Глава 2. Описание модели универсальной биллинговои системы 32
2.1. Универсальность как основа модели . 32
2.2. Подход, основанный на ресурсах 34
2.3. Структура системы 36
2.4. Расчетная часть ядра 40
2.4.1. Регистрация клиентов 41
2.4.2. Платежные планы, их отображение в ресурсы 41
2.4.3. Покупки 43
2.4.4. Платежи 46
2.4.5. Состояние покупки и контроль доступа 49
2.4.6. Корректировка лимитов 52
2.4.7. Структура расчетной части ядра . 53
2.5. Технологическая часть ядра 55
2.5.1. Взаимодействие с серверами доступа 56
2.5.2. Структура технологической части ядра 57
2.6. Синхронизация расчетной и технологической частей ядра 63
2.7. Организация дополнительных модулей и интерфейсов 66
2.7.1. Клиентский учет 66
2.7.2. Бухгалтерский учет 67
2.7.3. Дилерская система 69
2.7.4- Система оценки 69
2.7.5. Пользовательские интерфейсы . 71
2.8. Выводы по главе 2 72
Глава 3. Техническое и функциональное описание программной реализации 74
3.1. Техническое описание 74
3.1.1. Выбор среды разработки и программного обеспечения 74
3.1.2. Структура базы данных 75
3.1.3. Программные модули 78
3.1.4. Окружение 83
3.2. Функциональное описание 84
3.2.1. Регистрация клиентов 84
3.2.2. Платежные планы 84
3.2.3. Технологические ресурсы . 86
3.2.4. Платежи и покупки 87
3.2.5. Управление доступом к ресурсам . 89
3.2.6. Оценка потребленных ресурсов и расчет остатков счетов и лимитов . 91
3.2.7. Дилерская система 92
3.2.8. Карточки и авторегистрация . 93
3.2.9. Бухгалтерия 94
3.2.10. Информационные сервисы . 94
3.3. Выводы по главе 3 96
Глава 4. Контроль качества системы и возможности ее применения 97
4.1. Внедрение 97
4.2. Контроль качества 99
4.2.1. Производительность и масштабируемость 99
4.2.2. Надежность и достоверность . 102
4.2.3. Отказоустойчивость. Гибкость и переносимость 105
4.3. Возможности использования и развития . 106
4.3.1. Возможности использования . 106
4.3.2. Возможности развития 107
4.4. Выводы по главе 4 108
Общие выводы по работе 109
- История появления и развития биллинговых систем
- Подход, основанный на ресурсах
- Программные модули
- Производительность и масштабируемость
Введение к работе
Биллинговая система — это автоматизированная система расчетов фирмы-поставщика товаров или услуг с клиентами. Она предназначена для вычисления стоимости товаров или услуг исходя из определенных в ней данных о ценах, тарифах и других стоимостных характеристиках; для различных способов учета и обработки данных о клиентах, товарах, услугах, платежах и других объектах и событиях, а также для выставления счетов клиентам и организации прочих форм отчетов. Прототипы современных биллинго-вых систем зародились вместе с появлением первых вычислительных устройств, однако биллинговые системы в современном понимании (и сам этот термин) появились всего несколько лет назад [27,60,49].
Области, в которых используются биллинговые системы, могут быть самыми различными. В сущности, там, где есть взаимоотношения между продавцом и покупателем, биллинг присутствует так или иначе. Но самой благоприятной для развития и распространения биллинговых систем оказалась сфера телекоммуникаций и связи, поскольку, во-первых, здесь мы имеем дело с огромным количеством транзакций, которое невозможно отследить и обслужить вручную, во-вторых, данные для учета уже имеют цифровую природу, и не требуется человеческих ресурсов, чтобы вводить в компьютер основную часть информации, Биллинг успешно развивается и в других областях, в основном, связанных с обслуживанием: страхование, транспортные перевозки, аренда автомобилей, кабельное телевидение, муниципальные и коммунальные службы, гостиничное дело [60., 1, 25]. Как правило, для этих нужд разрабатываются независимые узкоспециализированные биллинговые системы.
Правильный выбор биллинговой системы критичен для прибыльности предприятия сферы обслуживания. На определенном этапе роста компании биллинг превращается из надежного и быстрого помощника в сборе и обработке информации в инструмент для расширения и усовершенствования сервиса на существующей технической базе [49], а значит, для привлечения новых клиентов. От надежности работы биллинговой системы зависит качество обслуживания клиентов и возможности, которые получает фирма-поставщик. Например, быстрое и точное получение статистических данных о продажах, предоставленных услугах и активности клиентов помогают вовремя определить новые векторы развития, спланировать мероприятия по усовершенствованию технических мощностей, вовремя отреагировать на новые требования потребителей. Все это очень важно в такой динамичной области, как телекоммуникации,
С конца 2000 года наблюдается заметный всплеск интереса к биллинговым системам в области телекоммуникаций и проблемам их разработки. Свидетельство тому — появление в научной печати статей, посвященных исследованиям в этой области, создание периодического журнала «Биллинг», проведение ряда семинаров, конференций и симпозиумов, в том числе, международных. Повышение спроса на разработку программного обеспечения этого направления, вызванное быстрым развитием телекоммуникационной отрасли, изменением структуры продаж и организации телекоммуникационного бизнеса, делают биллинг одним из самых динамично развивающихся направлений развития программных решений [25],
Отечественные производители ПО адекватно отреагировали на повышение интереса заказчиков к решениям в области биллинга. За ] 999 год появилось как минимум 6 тиражируемых биллинговых систем для телекоммуникаций. К осени 2002 года эта цифра превысила 50 тиражируемых систем. Изначально такие системы исполняются на заказ под конкретные нужды и требования заказчика, впоследствии их функциональность расширяется. Ряд разработчиков идет по пути распространения уже созданной модели биллинга на другие
области деятельности. Как результат, появляются новые узкоспециализированные решения для выполнения аналогичных функций в «смежной» области (система «Атлант» компании Атлант—Информ, «Барсум» петербургской компании Рексофт). Однако общая тенденция к универсализации биллинга, насущность разработки бил-линга «чего угодно и каким угодно образом» заставляет задуматься о построении такой модели биллинговой системы, которая могла бы позволить использовать единую систему в самых различных областях сферы обслуживания и торговли.
Предпосылки к этому создаются не только в области развития интернета и телефонии. Наметившиеся в последнее время тенденции к централизации коммунальных услуг, включающих телефон, интернет, кабельное ТВ, в новостройках и районах индивидуальной застройки естественным образом приводят к идее единой системы учета и контроля предоставления услуг. Та же самая тенденция намечается в гостиничном бизнесе, где спектр услуг является решающим фактором для клиентов. Комплексных биллинговых решений требуют и другие виды бизнеса, например такие, как аренда помещений, становящаяся популярной аренда программных приложений и т.п.
Речь идет не о том, чтобы учесть в системе все возможные требования рынка и сферы применения. Идея «конвергентного», или универсального, биллинга заключается в абстрагировании самого понятия сервиса и в его представлении как объекта с изменяемыми и неизменяемыми параметрами. При таком рассмотрении системе безразлично, что считать—секунды или байты, литры или киловатты, деньги или условные единицы. Построение такой модели позволило бы избежать в дальнейшем «утяжеления» системы при расширении сервиса или переносе системы на другие отрасли, где структура предоставления услуг схожа с телекоммуникациями [25, 44].
В работе предлагается модель универсальной биллинговой системы, обосновываются принципы и методы ее построения, описывается реализация предложенной модели, затрагиваются технологические вопросы построения биллинговой системы для оператора
интернет-услуг, даются результаты и показатели реальной эксплуатации биллинговой системы для телекоммуникаций, рассматриваются методы адаптации системы, построенной на данной модели, для других видов услуг и комплексных решений.
История появления и развития биллинговых систем
Прототипы современных систем, которые мы сегодня называем биллинговыми,породила телефонная индустрия. Автоматизация учета и обработки услуг начинается с момента появления первых телефонных станций. На базе абонентских отделов предприятий связи и машиносчетных станций производственно-технических управлений связи организовывались расчетные группы. Они занимались подготовкой данных для бухгалтерии и выпиской счетов. Проблема автоматизации ручного труда решалась по мере развития вычислительной техники. До появления первых отечественных арифмометров в 1935 году («томас-машипы») использовались импортные арифмометры («Архимедес», «Монро», «Рейнметалл»). В 60-х годах появились электромеханические арифмометры («Зоемтрон-214», ВММ-2). Наряду с арифмометрами использовались превосходящие их по скорости и точности вычислений перфорационные машины (или табуляторы), принцип работы которых основан на перфокартах. В 70-х годах начинается этап внедрения электроники в счетно-аналитическую технику, К середине десятилетия несколько производственно-технических управлений связи оснащаются ЭВМ класса «Минск-32», также практикуется аренда ЭВМ в больших ВЦ, Расчетные группы преобразовываются в расчетные центры. Постепенно устаревшие модели вытесняются более производительными машинами ЕС ЭВМ, а также малыми ЭВМ (СМ ЭВМ).
На базе техники с развитой системой программирования начинают разрабатываться специализированные программные комплексы для автоматизации технологических и экономических задач предприятий связи. С 1980 года начинается разработка АСУ-Связь системы автоматизации различного рода задач для отрасли связи. Координацию работ осуществляло Министерство Связи, были изданы нормативные методические и технологические документы, организованы информационно-вычислительные центры. Акцент делался на централизации управления проектом, однако такая политика не оправдала себя, и в 1990 году было разработано типовое техническое задание на АСУ-Связь и объявлен республиканский конкурс на лучшее се исполнение. Одной из самых лучших разработок была признана литовская система АСКР. Итоговый расчет для 300 тыс. номеров она выполняла за 12 часов, а при обнаружении ошибки нужно было запускать ее заново.
90-е годы открыли новое направление — для организации рабочих мест стало выгоднее использовать персональные компьютеры, для разработок стали применяться СУБД dBase, Clipper, FoxPro [39,53,61].
В 90 х годах, с появлением провайдеров интернет-услуг (Internet Service Provider, ISP), проблема автоматизации расчетов за услуги связи встает в новом ракурсе. Во-первых, интернет-провайдеры готовы предоставлять большой спектр разнообразных услуг, меняющихся и расширяющихся год от года. Во-вторых, конкуренция между провайдерами заставляет вести гибкую ценовую и маркетинговую политику. Свою расчетную систему провайдер организовывает с помощью штатных программистов. Это делает ее очень устойчивой на непрерывно меняющемся рынке информационных услуг и услуг передачи данных, но в основе таких систем вряд ли заложен комплексный подход и тщательное проектирование.
С появлением операторов сотовой телефонии, пейджинговой связи, IP-телсфонии появляются расчетные системы соответствующих направлений.
В 1998 году издается первый документ, регламентирующий требования к расчетным системам [2], а в 1999 году появляются первые тиражируемые системы для интернет сервис-провайдеров. Несмотря на очень слабое распространение в нашей стране расчетных систем импортного производства, расчетные системы приобретают устойчивое название «биллинговых».
Очень трудно обозначить время появления биллинговых систем как самостоятельной области разработки программного обеспечения. Принято считать, что системы биллинга в современном понимании существуют как у нас в стране, так и за рубежом, всего несколько лет. Однако столь молодое направлениеразвития автоматизированных систем имеет истоки и прототипы, а этапы его зарождения интересны не только как факты истории, но и как материал для изучения современных тенденций.
Подход, основанный на ресурсах
«Универсализация» — одна из современных тенденций и насущных задач в развитии биллинговых систем. С одной стороны, совершенствование технологий и сервисов, появление новых направлений в сфере телекоммуникаций и автоматизация различных областей жизни требуют постоянной модернизации биллинговых систем, а также их создания для новых сфер. С другой, успешная разработка и внедрение биллинговой системы влечет за собой идею ее дальнейшей доработки и расширения с целью применения в других отраслях [60].
В условиях быстро расширяющегося рынка телекоммуникаций оператор может пойти по пути совершенствования, доработки имеющейся у него системы биллинга, либо решиться на покупку и установку новой системы, охватывающий спектр возникших задач. Существует масса промежуточных решений, но все они являются компромиссами.
Использование небольших и узкоспециализированных систем может обернуться для оператора препятствием для дальнейшего расширения сервиса и реализации маркетинговых находок.
Однако охват биллингом большого информационного пространства (умение обрабатывать большое количество информационных ресурсов) хоть и является его преимуществом, но не может не отражаться на затратах на его разработку, внедрение и поддержку. Поэтому система, которая «умеет все», тоже не оправдывает себя. Кроме того, даже очень хорошо зарекомендовавшая себя на практике биллинговая система не может гарантировать тех функциональных возможностей, которые могут потребоваться от нее через годы.
Тем не менее, можно систематизировать спектр услуг, формализовать процесс их учета и унифицировать взаимодействие бил-линговой системы с серверами и программами, которые занимаются предоставлением казалось бы совершенно различных услуг.
Основная идея состоит не в том, чтобы реализовать или предугадать все новые возможности, а сделать их подключение своего рода «частью биллинга», то есть позволить «добавлять» в систему новые сервисы (ресурсы, технологии) через описание их свойств (параметров, категорий, форматов).
Проиллюстрируем сказанное примером. Организация, предоставляющая услуги интернет, планирует открыть услугу 1Р-телефонии. Компания может разработать или приобрести специализированный биллинг для ІР-телефонии либо расширить текущую бил-линговую систему для тарификации новой услуги. Выбор специализированного биллинга сразу накладывает существенные ограничения на деятельность оператора: невозможность единого учета клиентов, невозможность ведения общих счетов, дублирование информации, накладные расходы на поддержку двух систем учета [67]. Доработка текущей версии биллинговой системы может привести к непредвиденным сбоям, поскольку работа ведется на действующей системе «вживую», кроме того, как правило, такая доработка приводит к появлению нового модуля, а не изменению концепции, что в конечном счете превращает биллинг в «лоскутное одеяло» [63], Замена же существующего биллинга на принципиально новый, поддерживающий функции старого и учитывающий новые требования, может оказаться сложной технической проблемой, также не лишенной побочных эффектов.
Но в то же время алгоритмы учета, например, online-доступа (традиционной услуги интернет сервис провайдера) и услуг IP-телефонии во многом совпадают, это могло бы позволить без труда объединить эти функции в одной системе, если в ее модели заложена идея универсальности.
До сих пор мы говорили об услугах, не расшифровывая это понятие, считая его интуитивно понятным. Мы рассматривали услугу в обычном понимании, с точки зрения пользователя этой услуги. Рассмотрим, что представляет собой услуга с точки зрения технологического процесса, опираясь на примеры услуг передачи данных.
Подключение к сети интернет по коммутируемой телефонной линии (dial-up) предполагает дозвон на модемный пул интернет-провайдера и получение IP—адреса. ТР-адрес может выделяться клиенту динамически из пула IP—адресов провайдера только на одну сессию или же быть для клиента постоянным. Во втором случае IP-адрес закрепляется за клиентом и уже не может быть выдан другому клиенту. В сущности, технологический процесс распадается как минимум на два этапа; с точки зрения технологии одновременно предоставляются две независимые услуги, хотя клиент может даже не замечать этого.
Наличие статического ТР-адреса необходимо также для получения клиентом электронной почты по протоколу SMTP, но недостаточно — клиент должен иметь почтовый ящик (возможность пользоваться почтой) и домен.
Домен, в свою очередь, может использоваться для других целей, например, для создания виртуального www-сервера. Информационное наполнение этого сервера определяется еще одной компонентой — величиной дискового пространства.
Программные модули
Модуль синхронизации расчетной и технологической подсистем выполняет следующие функции: - определение состояний всех покупок в каждый момент времени; - обновление состояний покупок, внесение данных об обновле ниях в журналы; — выполнение различных действий, связанных с изменением со стояния покупки клиента: автоматическое создание зависимых покупок (например, бонусов и дополнений), управление насле дуемыми покупками (активация отложенных покупок, выстро енных в цепочки наследования), обновление статуса пользова теля в зависимости от состояния его текущих покупок, обно вление состояния и лимитов ресурсов в зависимости от состоя ния его покупок и атрибутов активных покупок. Этот модуль должен обеспечивать обновление больших таблиц в режиме, близком к реальному времени. Поэтому он должен быть хорошо оптимизирован по быстродействию. Несмотря на то, что модуль работает фактически со всей клиентской базой покупок, реальные обновления происходят не часто, следовательно, самая большая нагрузка ложится на отслеживание изменений в параметрах покупок клиентов, которые могут привести к изменению состояние покупки. Поэтому все поля, в которых содержатся атрибуты покупки, влияющие на состояние покупки, должны быть проиндексированы. Условия соответствия состояний описаны в мета-таблицах базы данных, при этом особо описываются переходы состояния С С (т.е. в то же состояние), чтобы в первую очередь исключить бессмысленные обновления. Метаданные также описывают приоритеты обновления состояний с тем, чтобы более сложные условия проверки соответствия состояниям выполнялись в отношении возможно меньшего числа записей.
После обновления состояний покупок иногда необходимо произвести ряд зависимых операций. Эти операции и их условия также описываются метаданными. Например, при переходе покупки в определенное состояние может быть изменено состояние связанной с ней покупки. Тем самым можно обеспечить параллельное или последовательное включение и отключение покупок и автоматическое создание новых покупок при выполнении определенных условий (суммарная выработка ресурса, срок действия договора и пр.) Эти операции выполняются над небольшим подмножеством покупок, поиск которых осуществляется по ключам обновленных записей.
Обновление состояний и лимитов ресурсов технологической базы данных помимо быстродействия нуждается в обеспечении надежности. Если даже на протяжении небольшого промежутка времени связь между расчетной и технологической базами потеряна, нужно гарантировать полную доставку измененных данных в технологическую базу. Для решения этой проблемы используются счетчики времени обновлений как в расчетной, так и в принимающей, технологической, базе. Принудительное обнуление счетчика времени в технологической базе позволяет произвести полное восстановление таблиц состояний и лимитов ресурсов из расчетной базы.
Программы, предоставляющие сервис, ведут журналы клиентских запросов и параметров потребленных ресурсов. Эти журналы содержат «сырые», необработанные данные и представляют из себя файлы того или иного формата. Модуль обработки первичных данных унифицирует «сырые данные», обрабатывает их и производит необходимые изменения в таблицах расчетной базы данных, изменяя те параметры клиентских записей, которые влияют на дальнейшее потребление сервиса.
Программы этого модуля реализованы по принципу «демонов» — процессов, работающих непрерывно. «Демон» читает записи в журнале логов, распознает типы записей, для каждой записи производит необходимые действия, когда записи кончаются, «демон» ставит указатель на конец файла и «засыпает». Через определенные интервалы времени «демон» проверяет, появились ли новые записи, обрабатывает их, сдвигает указатель и т.д. Такой подход избавляет программу от затрат на открытие и полное чтение файла первичных данных. Однако помимо указателя на последнюю прочитанную запись, программа должна сохранять какой-либо идентификатор последней записи, например, дату и время. Это может понадобиться в случае аварийной остановки процесса, В этом случае перезапуск «демона» избавит от потери данных или их вторичной обработки.
Действия, выполняемые демоном после чтения каждой записи, определяются типом ресурса и типом записи. В случае расходуемого ресурса после окончания предоставления ресурса происходит корректировка лимитов.
Производительность и масштабируемость
Модель системы, а также ее программная реализация могут быть использованы для тарификации, учета потребления и выставления счетов любых услуг, которые могут быть описаны в терминах ресурсов. В частности, система может найти применение в электронном бизнесе, телефонии, IP-телефонии, страховании, бизнесе, связанном с любыми формами аренды, коммунальной сфере и т.д. Технологическая подсистема при этом может претерпеть ряд изменений и доработок, которые, однако, не коснутся модели и ядра системы.
Помимо организации новых сервисов, система может быть доработана или настроена для организации новых платежных планов и типов учета (кредитование, работа с кредитными картами, платежи через интернет). Для этого потребуется введение новых модулей и частичная доработка ядра.
Система может быть дополнена любыми модулями, в которых возникнет необходимость, например, интерфейсы с офисным документооборотом, стандартными клиентскими приложениями, бух-галтерскими.финансовыми системами,модулями,обеспечивающими взаимодействие с другими биллинговыми системами, например, прироумингс.
Предложенная модель биллинговой системы позволяет реализовать внешний биллинг, эксплуатация которого может осуществляться несколькими удаленными узлами одновременно. При этом сам биллинг будет выступать в роли ресурса, а операторы в качестве клиентов.
В данный момент биллинговая система успешно эксплуатируется в телекоммуникационной компании — Санкт-Петербургском филиале ЗАО «Ситилайн». Система зарекомендовала себя как надежный и удобный продукт и имеет положительные отзывы руководства и персонала компании.
Проведенный автором анализ производительности и масштабируемости, основные результаты которого представлены в табл. 4.2 и нарис, 4.1, позволяет говорить о том, что система может бесперебойно работать с приемлемой скоростью на компьютерах класса Intel при базе 60 тыс. клиентов и при нагрузке 4000 звонков в час. Этот результат превосходит даже производительность биллинго-вых систем, основанных на новых, более производительных технологиях постреляционных баз данных [68]. Для сравнения, система MoBill, перенесенная на технологию постреляционной базы данных Cache, гарантирует качественное обслуживание базы в 20000 абонентов при средней нагрузке 2 000 000 звонков в месяц на процессоре Pentium 111-733.
Также приемлемыми оказались точность расчетов, надежность и отказоустойчивость системы и ее переносимость. Все эти характеристики были изучены в процессе эксплуатации.
Среди направлений развития данной системы в первую очередь следует указать возможность ее адаптации для предоставления таких услуг, характер оказания которых схож с телекоммуникациями, например, страхование, аренда, коммунальная сфера. Основная идея универсальности услуги, заложенная в модели системы, позволяет описать типы и характеристики достаточно большого класса услуг. Модульная структура системы является базой для развития ее функциональности, интеграции с другими системами, создания производственных комплексов.Предложенная модель биллинговой системы позволяет реализовать внешний биллинг, который сам может быть описан в терминах ресурсов, т.е. выступать в роли оплачиваемой услуги.
