Конвергентная система биллинга. |
|
Конвергентная система биллинга.
Конвергентный биллинг – понятие не
новое. Одним из значений слова
«конвергентность» является «свойство
схождения в одной точке». Прежде всего,
именно это и свойственно конвергентному биллингу. Именно в одной точке и сходятся все процессы, имеющие отношение к оказанию телекоммуникационных
услуг, и этой точкой является биллинг.
Тема конвергентного биллинга последнее время обсуждается очень интенсивно, как среди разработчиков, так
и среди собственно пользователей биллинговой системы. Трудно сказать, кто
же задает тон в данном диалоге. Первые
знают, как можно разработать, вторые
же знают, что, собственно, нужно. И когда эти возможности и требования совпадают, получается некий эффективный
продукт. Почему такое внимание эффективности? К сожалению, этому не всегда
уделяется внимание при разработке
требований к биллинговой системе.
Считается, что наиболее важно, чтобы
система работала корректно и, главное,
была быстро внедряемой. А «остальное»
приложится потом, в процессе работы.
Однако, на деле все нетак. Либо сразу
система биллинга формируется как продукт, который имеет множество качественных характеристик и возможность
развития, либо система билинга создается на основании требований сегодняшнего дня. Сегодняшний день всегда учитывает только первоочередные
задачи, которые не всегда в дальнейшем могут получить развитие. Обычно
они претерпевают значительную трансформацию, которая с трудом может
быть реализована наспех созданной
биллинговой системой. В результате система дописывается по кусочкам и получается некое аморфное подобие биллинговой системы.
Биллинг в компании оператора связи
предполагает три составляющие процесса. Первая – собственно пользователи системы биллинга. Т.е. те специалисты компании, которые занимаются
выставлением счетов и свойственных
этому процессу функций. Вторая – специалисты, обслуживающие и эксплуатирующие биллинговую систему как
программный продукт. Третья – специалисты, занимающиеся внедрением
биллинговой системы, а в дальнейшем
планирующие ее развитие в соответствии с вводимыми услугами и совершенствующимися требованиями бизнеса
компании.
Говоря о биллинге, мы уже получили
три точки соприкосновения с разными
бизнес–процессами в компании. Пользователи системы – это специалисты,
которые работают с биллинговой системой: вводят данные по клиентам, услугам, тарифам и прочим деталям. Это могут быть как специалисты одного организационного подразделения в компании, например, отдел биллинга, так
и нескольких. Например, это могут быть
сотрудники отдела продаж и службы обработки заказов. Причем они могутра
ботать как в биллинговой системе, используя свои собственные интерфейсы
(интерфейс – «рабочее место продавца»), так и через протокол обмена собственного программного обеспечения
с биллинговой системой. Т.е. при регистрации клиента в собственном программном продукте клиент автоматически появляется в базе данных биллинговой системы. Аналогичных решений мо
жет быть множество. Потому как все за
висит от бизнес–процессов в компании,
от наличия программных продуктов,
от подхода к реализации их взаимопроникновения и множества других факторов. Прежде всего, все определяется
конкретикой каждого оператора.
Именно пользователями биллинговой
системы осуществляется процесс тари
фикации и выставления счетов. Данные
по выставленным счетам заносятся на
так называемые карточки клиента или
лицевые счета. Эта функция выполняется любой биллинговой системой.
На карточке клиента отражена вся информация по оплате выставленных счетов за услуги. Поступление информации
по платежам в систему биллинга может
быть организовано по–разному.
Если
говорить о конвергентном биллинге,
то наиболее часто применяется следующее решение. Система биллинга имеет
интерфейс с финансовой системой, которая импортирует данные по текущим
платежам от клиентов. Биллинговая система имеет возможность быть настроенной на обработку и прием разных
стандартов информации от финансовой
системы. Обычно это некий блок про
граммы биллинга, который по заданным
критериям распознает платежи и соотносит их на карточки клиента. Некоторые биллинговые системы ведут учет
клиентов в базе по идентификационному номеру – Billing Account Code (ВАС).
Учитывать клиентов по их наименованию неудобно. Наименование может
быть слишком большим, т.е. состоять из
нескольких слов. Или же наименование
могут быть похожими – ООО «Связь»
и ОАО «Связь». Может быть и такая ситу
ация, когда клиент изменил свое наименование. Тогда, если учет клиентов ведется по наименованию, следует практически везде в биллинговой системе
в отношении этого клиента вручную внести соответствующие изменения (данная функция почти нигде не автоматизирована в Российский биллинговых системах). Если же учет клиента ведется по
идентификационному коду (ВАС), то до
статочно внести информацию о переименовании клиента только в его карточку. Все услуги и тарифы привязаны
к идентификационному коду и не требуют никаких корректировок в связи
с этим переименованием.
На карточке клиента также отражена
информация по услугам, потребляемым
клиентом. Это перечень услуг и их статус – отключены, активны и т.д. Эта информация может учитываться в биллинговой системе посредством ее регистрации в системе, либо путем создания
интерфейса и системой обработки заказов (Order Management).
В случае с конвергентным биллингом вопрос решается путем создания протокола обмена
информацией между двумя системами.
Основная работа с заказами ведется
в системе обработки заказов. Формиру
ется справочник по услугам, описываются статусы услуг, их характеристики.
Создаются группы свободных ресурсов
и тех, что находятся в эксплуатации.
В биллинговую систему поступает информация по уже введенным в эксплуатацию услугам для начала их тарификации и, при необходимости, по заказам других статусов. Оператор может давать
скидки за несвоевременно введенные
в эксплуатацию услуги. Эти скидки, как
и всевозможные начисления, выполняет
биллинговая система и работает в дальнейшем с результатами этих расчетов
как с обычным начислением за услуги.
Все данные поступают на карточку клиента. Если же услуги клиенту временно
отключены по любой причине, то биллинговую систему интересует только
статус услуги для возможности тарификации услуги. Всю работу с ресурсами
выполняют пользователи системы по
обработке заказов.
Вторая составляющая процесса представлена обслуживанием биллинговой
системы как программного продукта.
Специалисты, обслуживающие биллинговую систему, непосредственно занимаются вопросами, связанными как
с обслуживанием (сопровождением) системы, так и вопросами взаимопроникновения биллинга и смежных программ
ных продуктов. Другими словами, эти
специалисты производят администрирование биллинговой системы. Именно
на этом этапе осуществляется организация процесса обмена данными биллинга с другими системами. Здесь про
писываются варианты и уровни доступа
к информации в системе, регламенты
работы с данными.
Конвергентный биллинг предполага
ет довольно значительно количество
пользователей. При этом пользователи
могут быть рассредоточены по местам
подключения к системе как внутри офиса компании (например, в одном здании), так и территориально (в разных
районах города).
Очень важно правильно организовать
работу биллинговой системы как программного продукта. Система не должна «подвисать» и, ни в коем случае, «падать».
Уровень доступа к информации,
возможность оперировать с данными
могут быть организованы по–разному.
Наиболее простое решение – это организация доступа в соответствии со статусом на «рабочем месте» в биллинговой системе. Специалист по обработке
первичных данных, загружаемых в биллинговую систему от источников оборудования, не может сделать загрузку платежей в биллинговую систему. Администратор системы может «войти» в систе
му в любой ее функциональной области.
Однако бывают ситуации, когда ошибку
может исправить специалист–пользователь, который по статусу обычно не вы
полняет данную функцию. Присваивать
ему на час статус, позволяющий это
сделать, не всегда правильно, потому
как в данном случае система «журнали
рования» действий пользователей
в биллинговой системе должна быть
сложной и позволять фиксировать изменения статусов по уровню доступа и времени действий. Слишком сложная система журналирования в биллинговой системе реализуется трудно. Поэтому при
создании регламентов действий по статусам в биллинговой системе должны
быть предусмотрены нестандартные
действия при наступлении определенных ситуаций. Например, при возникновении ошибки на этапе загрузки платежей в биллинговую систему пользователь уровня «А» может остановить загрузку платежей и изменить ее критерии. При этом он не может изменять
данные в уже загруженных в систему
биллинга платежах.
Третья составляющая процесса биллинга – это развитие и совершенствование биллинговой системы. Необходимость выделения этой составляющей из общего процесса биллинга объясняется тем, что проблемы эксплуатации биллинговой системы и ее сопро
вождения не позволяют уделять должного внимания перспективам биллинговой системы. К сожалению, биллинг
никогда небыл той предметной областью, где все проблемы можно устранить раз и навсегда. Усовершенствование внедренной биллинговой системы
обычно происходит по функционалу системы (под «функционалом» следует
понимать функциональные возможности системы биллинга). Вводится новая
услуга (например, предполагается предоставлять голосовые услуги по технологии интернета VoIP, до этого были
только услуги классического интернета), и в соответствии с технологией
этой услуги в биллинговой системе настраивается новый функционал. Если
технология вновь вводимой услуги значительно отличается от технологии уже
оказываемых услуг, то к биллинговой
системе добавляется новый модуль,
позволяющий тарифицировать новую
услугу. Это так называемый Relies
Management. Совершенствование биллинговой системы может выполняться
как специалистами компании, так
и сторонней организацией (например,
консалтинговой компанией), или же командой состоящей из представителей
обеих компаний.
Еще одно направление перспективного развития биллинговой системы – это
не совершенствование действующего
функционала системы, а разработка действий в соответствии со стратегическим
планом компании оператора. Например,
компания оператор планирует развивать
свой бизнес в ближайшие 10 лет. Преж
де всего, это означает, что будут внедряться новые по своей технологии услуги. Значит надо рассмотреть возмож
ность действующей биллинговой системы быть либо «дописанной», либо следует произвести переход на новую биллинговую систему, или же и то и другое вместе. Действия команды специалистов,
в задачи которых входит развитие биллинговой системы, должны быть согласованы и с технической политикой компании – необходимо знать, какое оборудование планируется вводить в эксплуатацию для оказания услуг; и с политикой
развития бизнеса – будет ли компания
оставаться на данном сегменте рынка
или же будет стремиться проникнуть
в новый сегмент рынка данных услуг;
и финансовой политикой – будут ли ока
зываться услуги на многовалютной основе (например, расчет в рублях и долларах
США) или же будет переход на новую систему финансового учета и т.д.
Из всех процессов, связанных с биллингом, направление развития биллинга
является наиболее сложным и интересным. Любые изменения на рынке услуг
или в экономике вносят свои корректировки в стратегические планы. С точки
зрения конвергентного биллинга, когда
в единое целое связаны несколько систем, поддерживающих бизнес–процессы компании, нельзя развивать только
какую–то одну из этих систем.
Если вернуться к примеру о вновь вводимой услуге с технологией, отличной от оказы
ваемых услуг на данный момент, то глобальные изменения должны произойти
не только в части тарификации и вы
ставления счетов, но и в системе по обработке заказов, по учету ресурсов, их
описанию в системе биллинга.
Биллинговая система может иметь
множество точек соприкосновения с системами, поддерживающими бизнес–процессы компании, так называемые Operation Support Systems. Это такие системы, поддерживающие бизнес–процессы, как
Customer care (Customer Relationship
Management) – работа с клиентами;
Sales Management – продажа услуг;
Network Management – управление
и мониторинг сети;
Order Management – обработка заказов;
Trouble Tickets Management – обработка проблем, учет и контроль.
Биллинговая система зачастую ориентирована на Продукт–каталог компании оператора. Ведь именно Продукт–каталог является сборником правил и действий в отношении оказываемых услуг компанией. Согласно планам
развития компании формируется и Про
дукт–каталог, который может быть создан как внутри системы биллинга, так
и в независимом программном продукте, например в Business Development
Management. В случае конвергентного
биллинга Продукт–каталог ведется во
внешней среде по отношению к биллинговой системе. Однако биллинговая система выполняет ряд ограничений по отношению к операциям внутри себя в со
ответствии с Продукт– каталогом. Если
в Продукт–каталоге описана услуга
«аренда канала» и указаны ее характеристики, то, присваивая клиенту услугу
«аренда канала», мы не сможем ему указать в качестве характеристики услуг
АОН (аудентификационный определитель номера), свойственный услугам голосовой связи.
Необходимость создания конвергентного биллинга появилась одновременно
с ростом конкуренции на рынке услуг
связи, когда уже нельзя было удержать
клиентов только за счет ценовой политики. Необходимо было совершенствовать работу компании оператора, повышать ее эффективность и снижать затраты, а следовательно, и цены на услу
ги, за счет внутренних резервов компании. Согласованность действий и сокращение времени на принятие решения
в компании позволило стать первыми
направлениями действий к поиску решений оптимизации бизнеса.
Как показывает практика ведущих мировых операторов телекоммуникационных услуг, задача внедрения конвергентного биллинга рано или поздно появляется у любого оператора, имеющего в своих стратегических планах стать
лидером на рынке телекоммуникаций.
В конце 90–х годов была создана ассоциация (www.tmforum.com), в которую
вошли лидеры рынка телекоммуникационных услуг. Результатом работы ассоциации являются всевозможные конференции, встречи. Данной ассоциацией
был разработан документ (Telecom
Operation Map), представляющий собой
консолидированный взгляд специалистов на бизнес–процессы телекоммуникационных компаний.
В зависимости от масштаба компании оператора
в биллинговый процесс включаются все
больше функций, ранее не свойственных биллингу, но в свете создания конвергентного биллинга получивших развитие как равноправные области биллингового процесса. Например, по результатам обработки первичных данных (Call Direct Record) при обнаружении записей, «маски» которых не соответствуют описанным в системе биллинга, автоматически направляется запрос в систему по контролю за нарушениями. Система по контролю за нарушениями производит анализ данных и,
если это результат ошибки в настройках системы биллинга, направляет распоряжения на устранение ошибки, либо, если это результат сбоя в сети, на
правляет запрос в систему менеджмента и мониторинга сети. По согласованию в биллинговой системе на стадии
обработки данных можно настроить новый алгоритм принятия решений в свете обнаруженных сбоев таким образом,
что при появлении записей CDR, вызванных ошибками в сети, система будет автоматически оповещать систему
контроля сети и переводить данный вызов услуги на альтернативный маршрут, используя систему управления сетью. Другими словами, пользователю
услуги, предоставленной со сбоем, система биллинга может автоматически
присвоить в сети другой маршрут соединения и сразу же предоставить
скидку в расчетах за услугу, оказанную
со сниженным качеством.
Идея конвергентного биллинга обоснована еще и техническими возможностями. Многие программные продукты
класса OSS используют аналогичные базы данных. При создании конвергентного биллинга эти базы данных легко проникают друг в друга, а иногда и создается одна база данных, в которой образуются сектора для обращения того или
иного запроса от систем OSS.
С ростом числа абонентов биллинговая система должна иметь возможность
быть масштабируемой. Если архитектура биллинговой системы по своему типу
многослойна и пронизана, как иголкой,
стержнем, вокруг которого и строятся
все действия, то развивать ее путем до
бавления новых блоков значительно
сложнее, нежели биллинговую систему,
архитектура которой похожа на «кубик»,
состоящий из маленьких кубиков. Если
расширить возможности только блока
тарификации (Call Rating) и выставления
счетов (Invoicing) и не расширить при
этом блок по работе с клиентами
(Customer Care/CRM), то система биллинга в скором времени начнет давать
сбои и явно снизится ее эффективность.
Нельзя забывать и о таком требовании
к продукту, как эргономические свойства. Система биллинга должна быть «понятной» для пользователя. С некоторыми интерфейсами биллинговой системы
будут работать специалисты разного
профессионального уровня.
Автор: независимый эксперт - Елена Гусева
guseva@online.ru
