5.6. Общее представление о системе управления предприятием

Описание функций и возможностей клиентского уровня УБС было бы неполным без

упоминания взаимосвязи этого уровня с системами управления предприятием (СУП) и, в частности, с системами управления ресурсами (СУР) оператора (Enterprise Resource Planning, ERP). Надо отметить, что если первоначально аббревиатура СУР

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

УБС важно понимать, что СУП является одним из ключевых элементов управления предприятием как в части управления связями с потребителем (Customer Relationship Management, CRM) и управления цепями поставок (Supply Chain Management, SCM)

услуг, так и управления жизненным циклом продукции (Product Lifecycle Management, PLM) в части предоставления услуг и использования финансовых платежных инструментов. В данном разделе будут определены конкретные службы, с которыми должен взаимодействовать КУ УБС, а также основные потоки обмена информацией.

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

–бухгалтерия;

–маркетинг и планирование ресурсов;

–финансово-аналитическая служба;

–служба ведения и контроля договоров (учет абонентов);

–служба продаж абонентского оборудования;

–служба подключения и абонентского сервиса (в т.ч. ремонт);

–информационно-справочная служба;

–служба безопасности.

Еще раз необходимо подчеркнуть, что речь идет не о всех направлениях СУП, а только о тех, с которыми в большей мере взаимодействует УБС.

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

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

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

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

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

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

Все вышеизложенное касается и справедливо в большей степени для состав- ляющих SCM и PLM. Как указывалось выше, одной из определяющих частей BRP является CRM (управления связями или взаимоотношениями с потребителями). CRM как составляющая системы управления предприятием реально лежит в основе оптимального функционирования биллинговой системы. При этом оптимизация должна пониматься не только в контексте прямого воздействия на абонента, но, что более важно, в контексте обратной связи между абонентом и оператором, заклю- чающегося в предоставлении абонентам возможности посылки запросов, контроля и объединения счетов, получения необходимых справок и т.д. Основная тенденция такого взаимодействия предусматривает два важных фактора. Во-первых, это взаи- модействие должно осуществляться в реальном времени и быть актуально, а во- вторых, должно вызывать безусловный отклик оператора. Если первый фактор обеспечивается технологическими возможностями CRM (контакт-центрами и кор- поративными порталами), то второй фактор должен обеспечиваться оптимизацией бизнес-процессов компании оператора, характеризуемой внутриуровневой и межу- ровневой интеграцией СУП. Это, в свою очередь, позволяет осуществлять про- смотр и контроль всех объектов и сущностей, характеризующих данного пользова- теля или группу пользователей, что позволяет строить оптимальную маркетинго- вую политику для разных сегментов рынка.

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

5.7. Техническая архитектура УБС

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

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

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

Как упоминалось выше, функции SSP выполняют все шлюзы с сетями коммута- ции каналов и пакетной коммутации, в том числе сама ГИС как шлюз «горячего биллинга» с фиксированной и подвижной телефонной сетью.

Сервер SCP обеспечивает выполнение услуг и обработку CDR (напомним, что в общем виде CDR трактуется как запись детализации соединения — Connection De-

tail Records), генерацию транзакций — TR (тарифицированные CDR), выполняет функцию управления услугами и поддержки данных. Сервер SCP CBSN (верхнего уровня УБС) имеет прямой доступ к серверу поддержки данных (SDP), а также обеспечивает взаимодействие с SCP PBSN (нижнего уровня УБС).

Рис. 5.11. Структура аппаратно-программного комплекса УБС

Сервер поддержки данных (SDR) содержит базы данных, необходимые для функционирования УБС. Доступ к SDP из SCP нижнего уровня может быть полу- чен либо через соответствующие шлюзы, либо через сервер SCP или сервер обеспе- чения услуг (SMP). Различные сервера поддержки данных, в том числе клиентского уровня, могут быть связаны друг с другом.

Сервер администрирования услуг выполняет функции SMF, SMAF и функцию среды создания услуг SCEF. Данный сервер обеспечивает управление базами дан- ных, мониторинг сети, управление нагрузкой и обработку статистики, а также из- мерение различных характеристик системы биллинга.

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

На рис. 5.13 показана возможная структура аппаратных средств УБС для про- вайдера услуг Интернета, который предоставляет услуги коммутируемого и посто-

янного доступа в сеть Интернет, а также дополнительные услуги, и осуществляет биллинг в режимах hot-line pre-paid off-line post-paid.

Рис. 5.13. Пример структуры аппаратного комплекса для Интернет-провайдера

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

На рис. 5.14 показана обобщенная структура программного комплекса УБС. Структура включает в себя шесть основных функциональных блоков: управляющее ядро, СУБД информационного и клиентского уровней, программные шлюзы, поль- зовательские и административные интерфейсы.

Рис. 5.14. Обобщенная структура программного комплекса УБС

Прежде чем приступить к более детальному рассмотрению этих функциональ- ных блоков, необходимо дать несколько уточнений. Прежде всего, надо отметить, что для определенного класса средних и малых УБС, СУБД КУ и СУБД ИУ могут объединяться в единую СУБД. Далее, определение интерфейсов КУ как пользова- тельских интерфейсов следует понимать в том смысле, что к категории этих интер- фейсов относятся и интерфейсы взаимодействия УБС с непосредственно пользова- телями (абонентами). И наконец, под термином «программный шлюз» (ПШ) в дан- ном контексте понимается его программная поддержка, а разделение шлюзов на шлюзы с сетями коммутации каналов (СКК) и на шлюзы с сетями с пакетной ком- мутацией (СПК) в явном виде соотносит данный ПШ с видом сети, несмотря на то, что, например, ПШ, который взаимодействует по каналу сигнализации ОКС №7 с сетью коммутации каналов, мы относим к СКК, хотя обмен информацией осущест- вляется в виде пакетов.

Управляющее ядро. Будучи функционально-управляющим блоком, ядро УБС является совокупностью функциональных модулей (Management Functional Module, MFM) и управляющих модулей (Applications Manager Module, AMM) — непосред-

ственных диспетчеров алгоритма функционирования услуги.

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

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

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

Для примера рассмотрим набор MFM для функциональной компоненты автори- зации СКК. Как указывалось выше, функциональная компонента авторизации (FFa) декларирует свою систему отношений в области видов и типов биллинга, а также в

области форматов информации, приходящей из различных сетей. Так, для авториза- ции по номеру терминала для hot-line биллинга из СКК или СПК FFa получает за-

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

тат авторизации, формализует и передает ответ на запрос. Для авторизации по но- меру терминала для on-line (off-line) биллинга из любой сети (в частности, для СКК

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

Второй пример, иллюстрирующий данный подход, это реализация функцио-

нальной компоненты тарификации. Рассмотрим тарификацию pre-paid hot-line и post-paid off-line для услуг СПК, в частности коммутируемого (dial-up) и постоян-

ного доступа в сеть Интернет. Для случая pre-paid dial-up тарификация производит- ся по оплаченному времени доступа с выделением (для корпоративного пользова- ния, т.е. когда по одному лицевому счету могут получать услугу несколько пользо- вателей) определенных оплаченных квантов времени с контролем остатка по соот- ветствующему лицевому счету. Таким образом, функциональная компонента тари- фикации должна обеспечить: обработку запроса на тарификацию в реальном режи- ме времени, реализацию запроса к базе данных о состоянии счета, выборку тариф- ного плана, выделение кванта времени, а по его окончании запрос следующего кванта, по окончанию предоставления услуги подготовку CDR в виде записи в транзакцию стоимости оказанной услуги. Для post-paid off-line постоянного досту- па к сети Интернет тарификация проводится по объемам принятой и переданной информации. Для выполнения тарификации программным шлюзом уже подготов-

лен соответствующий CDR, в котором указаны эти объемы. Соответствующий про- граммный модуль находит в базе данных тарифный план данного пользователя и проводит соответствующую тарификацию, т.е. тарифицирует готовый CDR, пре- вращая его в транзакцию. Как видно из приведенного примера, имеются мало сход- ных функций, позволяющих унифицировать данную функциональную компоненту в виде общего функционального модуля. На рис. 5.15 для примера приведены от- дельные из рассмотренных выше модулей.

Рис. 5.15. Взаимосвязь функциональных, управляющих и интерфейсных модулей

Программные шлюзы. Основной функцией программных шлюзов hot-line и offline является поддержка взаимодействия между управляющим ядром и программно- аппаратными средствами сбора и обработки информации о состоявшихся соединени- ях, характеризующих предоставление той или иной услуги, или соединениях, кото- рые должны состоятся. В терминах функциональных модулей эти программные мо-

дули взаимодействия в режиме hot-line можно назвать модулями обработки событий

(Events Processing Module, EPM), а для режима off-line — модулями обработки запи- сей (Records Processing Module, RPM), имея в виду, что через шлюзы hot-line произ-

водится обмен запросами, а через шлюзы off-line — обмен записями.

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

просами авторизации и тарификации — MRP (Roaming Processing Module), а для перевода — BPM (Banking Processing Module)

Программные шлюзы межуровневого взаимодействия осуществляют программ-

ное взаимодействие между информационным и клиентским уровнями и реализуют-

ся на основе программных модулей MII (Interlevel Interface Module).

Рассмотрим более подробно отдельные модули.

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

ся по типу используемого протокола, так, в частности, для СКК обычно использу- ется верхние уровни протокола TCP/IP, а для СПК — протокол Radius. В этом слу- чае можно говорить о модулях СКК как EPMc (canel) и EPMb (burst) для СПК.

RPM должны обеспечивать съем и предварительную обработку CDR, которые накапливаются в оборудовании, предоставляющем услуги связи. Несмотря на опре- деленную стандартизацию форматов CDR, которые накапливаются в оборудова- нии, в общем случае RPM отличаются как для стыка с оборудованием различных сетей (соответственно, RPMc и RPMb), так и реально отличаются даже для разного оборудования одного типа сетей.

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

BPM функционирует как модуль безопасного перевода счетов из одной УБС другую в случае, если технология функционирования УБС предусматривает «ми- грацию» счетов из одной УБС в другую. Дополнительной функцией BPM является возможность отражения в базе данных счетов истории их миграции. Это позволяет при получении запроса из другой УБС на перевод счета, который уже переведен, указать «адрес» УБС, к которой необходимо обратиться по данному паролю досту- па к счету. Согласование протоколов сети обмена информацией обычно произво- дится на уровне аппаратных средств.

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

Базы данных информационного и клиентского уровней должны содержать совокупность постоянной и переменной информации, необходимой и достаточной для функционирования универсальной УБС. В общем случае базы данных включа- ют в себя информацию о договорах, клиентах, обо всех типах счетов, CDR, тран- закциях, тарифных планах, отчетах, выставленных платежах и расчетах по ним, а также данные статистики, справочные каталоги и другую информацию, необходи- мую для функционирования системы. Распределение баз данных на информацион- ный и клиентский уровень является достаточно условным (см. рис. 5.14). В то же