Гарантирование доходов и противодействие мошенничеству в телекоммуникационных компаниях

Ориентация на клиента — главный вектор операторского бизнеса

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

При
этом цель оператора связи, в трактовке председателя TMF К. Уиллетса, —
«получать больше, вкладывать меньше». Для этого требуется решить следующие
задачи:

повысить
скорость и качество внедрения новых услуг и сервисов;

повысить
активность бизнеса (включая финансы, маркетинг, партнерство, новые
бизнес-модели работы на рынке);

сократить
эксплуатационные расходы;

повысить
качество обслуживания клиентов и, как следствие, их лояльность.

Предположим,
оператор построил сеть следующего поколения (NGN) или собирается предоставлять
новые услуги на базе существующей сети, или у него недостаточно хорошо, по его
мнению, идут продажи «старых» услуг и он решил внедрить систему отношений с
клиентами (CRM). Для этого ему необходимо представить и организовать
соответствующие процессы как внутри компании, так и вовне.

Организация
процесса предоставления услуг нового поколения оператором связи состоит из
четырех этапов:

1.
Классификация услуг, учитывающая особенности маркетинговой стратегии оператора
связи.

2.
Определение и описание сквозных процессов предоставления услуг, выработка
ключевых показателей (метрик) процесса предоставления услуги в соответствии со
стратегическими целями компании.

3.
Оптимизация процессов с учетом их стоимости и необходимой мотивации персонала.

4.
Автоматизация процессов с использованием информационных систем класса OSS/BSS
(начиная с постановки системы CRM) с четко определенными при оритетами их
внедрения и принципами взаимодействия между собой.

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

What are OSS/BSS Systems?

Operational support systems (OSS) are used by telecommunications (telco) providers to monitor, control, analyze, and provide the technical support for interface functionality. Business support systems (BSS) help run a provider’s business operations, assuring customer satisfaction and revenues gain.

Together, OSS and BSS communicate to support customer-facing activities and various end-to-end telecommunication services. Both possess their own specific data and service responsibilities to assure providers meet network fulfillment requirements.

Telco companies use OSS/BSS to:

  • Optimize network interface

  • Fine-tune network services for a defined a geographical area

  • Maintain the mobile and fixed infrastructure of the network

  • Administer provider services to network customers

Buyers should check any existing software or services for suite-style offerings that already include OSS/BSS capabilities. Products in the following categories can be cross-referenced for similar products:

OSS/BSS Systems Features

OSS/BSS features are typically used by network architects and engineers to monitor, maintain, manage, and optimize network systems. OSS and BSS work in tandem. An OSS shares customer orders, network faults, and service assurance data; and a BSS processes that data to meet fulfillment requirements.

Standard features in OSS are:

  • Network configuration & provisioning

  • Fault management

  • Overlay networking (SDN overlay)

  • Post/Pre-Paid systems

  • Service Request management

Standard features in BSS are:

  • Service provisioning

  • Revenue management (billing)

  • Delivery of services administration

OSS/BSS Systems Comparison

When comparing OSS/BSS products, consider the system’s capacity to launch quick and cost-efficient services that keep up with optimization demands. Telco companies provide phone and internet services to a defined geographic range that may be developed over time. To provide consistent and quality service, network engineers and architects must plan, build, and continuously optimize their network interface and infrastructure.

The ease of use and integration capabilities of existing products should also be considered when evaluating OSS/BSS products. Fragmentation is avoided and the quality of the network is improved when OSS and BSS communicate efficiently. Other notable factors include deployment options, support systems, or training opportunities.

Pricing Information

OSS/BSS systems rely on a client-centric model. They must differentiate service strategies to assure agile deployment of new services, so price ranges depend on a network’s needs.

Standard OSS/BSS features are accessible on open source or cloud-based solutions, starting at $2-$10 per month. More complex OSS/BSS systems with revenue tracking and network monitoring features require contacting vendors for quotes.

Larger operators with global networks or civic responsibilities may cost thousands to millions of dollars for a single licensing fee with an annual subscription.

The following price ranges are approximate estimates:

Поставщики

Основная статья: OSS/BSS

Рынок поставщиков OSS/BSS систем достаточно динамичен, и на нем присутствует множество игроков. Это как ИТ-гиганты, такие как Hewlett-Packard и IBM, так и малоизвестные компании, специализирующиеся исключительно на этом рынке. По оценкам аналитиков, наиболее распространены OSS/BSS решения следующих производителей:

  • Hewlett-Packard
  • Alcatel-Lucent
  • IBM
  • Micromuse (в 2006 году куплена IBM, после чего вошла в состав подразделения по производству программного обеспечения Tivoli)
  • Amdocs
  • NVision Czech Republic (ранее Ситроникс Телекоммуникационные решения) (FORIS BSS/OSS)
  • CBOSS
  • Naumen
  • Agilent Technologies

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

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

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

Приоритетность внедрения OSS/BSS

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

Подход
к определению приоритетов внедрения информационных систем для оператора связи
показан на рис. 2. Многие операторы связи при внедрении услуг NGN отталкиваются
от технологии и только потом задумываются, как предоставлять услуги

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

В
таком целостном видении рассматривается создание и внедрение любой
информационной системы, отвечающей задачам бизнеса оператора связи, а не
технологическим особенностям построения сетей оператора. Данный подход является
основополагающим, так как нацелен на удовлетворение требований клиентов и
позволяет определить эффективность от внедрения любой системы класса OSS/BSS.

70% поставщиков услуг ведут активные процессы модернизации своих OSS-систем, отмечая результаты уже на ранних стадиях проектов

8 августа 2011 года Amdocs объявила результаты глобального исследования, раскрывающего тенденции в области модернизации OSS-систем и различия в подходах к их модификации. В исследовании участвовали поставщики услуг по всему миру. Его результаты призваны помочь компаниям проанализировать относительное состояние своих проектов по модернизации OSS-систем.

Основные выводы исследования

  • 70% поставщиков услуг начали проекты модернизации OSS-систем в 2009-2011 гг: Только в этом году подобные проекты стартовали в четверти всех опрошенных компаний. Компании, охарактеризовавшие себя как инновационные, на 75% закончили процесс обновления. Отстающие находятся на ранних стадиях – в основном, не перейдя 25-процентный рубеж.
  • Операционные факторы являются наиболее приоритетными: Операционные драйверы, такие как повышение эффективности и снижение операционных издержек на работу OSS-систем являются важнейшими причинами для начала модернизации. Однако, как показало исследование, ИТ-сфера все больше увязывается с бизнесом, и на необходимость обновления OSS все чаще влияют бизнес-факторы и необходимость повышения качества обслуживания.
  • 33% поставщиков услуг получают измеряемый количественно результат от модернизации OSS: Несмотря на то, что многие компании находятся на ранних стадиях проекта обновления, 39% из них заявили, что они уже получили ощутимую выгоду от этих проектов. Это, в частности, ускорение запуска новых продуктов, возможность создания нишевых продуктов, ускорение движения денежных средств, снижение операционных затрат, поддержка большего количества потребителей и снижение числа жалоб от них, уменьшение оттока клиентов, поддержка новых сервисов, например machine-to-machine (M2M).
  • Регионы демонстрируют различные подходы к модернизации OSS: Исследование выявило, что для модернизации OSS используются совершенно различные подходы. Так, в Европе поставщики услуг фокусируются на контроле затрат и целью обновления OSS считают повышение производительности инфраструктуры и поддержку новых услуг. В Северной Америке компании озабочены эффективностью OSS-систем и стремятся повысить их гибкость для поддержки запуска новых услуг и сервисов. В Латинской Америке компании заинтересованы в ускорении бизнес-процессов и конвергенции между отдельными направлениями бизнеса. В Азии основными драйверами модернизации является снижение расходов и запуск новых услуг.

Список литературы

Журнал
ИнформКУРЬЕРсвязь №9, 2005 г.

Если Вам нужна помощь с академической работой (курсовая, контрольная, диплом, реферат и т.д.),
обратитесь к нашим специалистам. Более 90000 специалистов готовы Вам помочь.
Бесплатные корректировки и доработки. Бесплатная оценка стоимости работы.

Подробнее

Поможем написать работу на аналогичную тему

Реферат

Любая тема

От 850 руб.

Контольная работа

Любая тема

От 850 руб.

Курсовая

Любая тема

От 1500 руб.

Получить выполненную работу или консультацию специалиста по вашему учебному
проекту

Узнать стоимость

Нужна помощь в написании работы?
Мы — биржа профессиональных авторов (преподавателей и доцентов вузов). Пишем статьи РИНЦ, ВАК, Scopus.
Помогаем в публикации. Правки вносим бесплатно.

Узнать цену

Внедрение систем защиты

Конечно, создание такого «индивидуального» набора инструментов для телекоммуникационной компании требует тщательного обследования последней. Необходимо проанализировать действующие в компании системы, процессы, предоставляемые услуги и т. д. Цель такого обследования (FM&RA-аудита) – выявить в компании существующие на данный момент проблемы потери доходов и фродовые схемы, приоритезировать их в соответствии с масштабом потерь и вероятностью их возникновения и разработать поэтапный план развития инструментальной части LPC.

Естественно, что сложноорганизованный инструментальный комплекс FM&RA требует и соответствующей организационной и процедурной поддержки.

Для этого в LPC существует организационная составляющая, которая подразумевает формирование в компании подразделения, ответственного за реализацию функций FM&RA. В его задачи должны входить координация выполнения  процедур FM&RA всеми вовлеченными в них структурами компаниии, разработка новых процедур, управление внедрением и  эксплуатация программных комплексов FM&RA, формирование и предоставление отчетности высшему руководству по специально разработанным KPI, характеризующим как ситуацию с гарантированием доходов в компании в целом, так и эффективность работы самого FM&RA-подразделения.

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

Все это позволяет наиболее оптимально использовать внедренное решение и добиться наибольших результатов в борьбе с фродом.

Отметим, что правильно реализованная концепция Loss Prevention Center позволяет решить три основные задачи современной функции Fraud Management & Revenue Assurance:

  1. Поэтапное внедрение – от закрытия самых критичных и/или «лежащих на поверхности» проблем утечки доходов к стопроцентому покрытию всех возможных рисков потерь.
  2. Экономическая целесообразность – затраты на создание FM&RA-функции не должны превышать экономическую выгоду от ее внедрения.
  3. Превентивность – проблемы должны предотвращаться, а не обнаруживаться.

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

Модули

ИТ-инфраструктура постоянно усложняется. Весь этот регулярно меняющийся и растущий вычислительный комплекс, комплекс сетей связи и систем жизнеобеспечения необходимо поддерживать и обслуживать. Без средств автоматизации решить эту задачу невозможно, так как человеческие ресурсы, как правило, ограничены. Средством автоматизации ручного труда, в данном случае, являются системы операционной поддержки. Эта аббревиатура объединяет несколько подклассов систем, включая мониторинг (Fault Management), сбор и анализ производительности (Performance Management), медиацию (сбор данных от разнородного оборудования и приведение их к общему виду), SIEM (Security Information and Event Management) сбор и обработка данных от средств информационной безопасности и ряд других систем.

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

По оценкам экспертов, несмотря на постоянное совершенствование технологий связи, потери от мошенничества в телекоммуникационных компаниях достигают 3–10% от общего оборота. Примечательно, что для большинства организаций этот показатель колеблется в пределах 5–7%. Одним из наиболее важных классов OSS/BSS системы является Fraud Management, что дословно переводится как «управление мошенничеством».

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

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

С помощью решений класса Fault Management создаются системы для эффективного управления телекоммуникационными ресурсами. Нередко Fault Management интегрируется с Help Desk решениями. По оценкам экспертов, внедрение систем такого класса позволяет существенно уменьшить их TCO (Total Cost Ownership — полная стоимость владения).

Аналитики различают несколько возможных способов построения OSS/BSS решения на предприятии. Так или иначе, каждый вариант сводится к интеграции различных классов OSS/BSS с другими информационными системами и/или классами. Это может быть Fault management&Trouble ticketing + SLA management + CRM, или Fraud Management + биллинговая система + СRM, а также другие способы. Каждая комбинация обеспечивает решение определенного класса наиболее критичных для заказчика бизнес-задач. Выбор делается на основе комплексного анализа всех бизнес-процессов компании.

Would you say testing in OSS/BSS is a trivial task? Definitely not

It usually takes at least a couple of days just to test functionality. While implementing a new system/subsystem or changing functionality, there are so many questions to be answered. Which product to choose for testing? Which tariff plan to choose for testing? What kind of charges to check, and what type of subscribers to use?

It is obviously impossible to cover all possible options and combinations during functional testing, so it is necessary to select the most important products and services.

At this point, the thought comes to mind to turn to the good old engineering approach of back-to-back testing, which is based on the law of large numbers. The point is simple: It is necessary to compare system behavior using the same data. Imagine that we have two environments:

  1. Production — your live system serving subscribers
  2. Testing — your environment intended for testing.

First, at a specific date/time, usually after a billing period has been completed, we transfer copies of user data (migration data) and the product catalog (configuration data) to the testing stand. At the end of the reporting period (month or week, depending on the timing of the invoice), a copy of the input data for each transaction (payments, charges, maintenance fees) is loaded into the testing environment.

First, the output data has being processed from both environments. Second, it is placed on a comparison server. Then, specially developed script checks if the number of transactions and the charges from both environments match. The matching and unmatched numbers, the results of this comparison, are the input data for testers.

What’s next? The testing team goes to work. Testers analyze the records based on any discrepancies between the two sets of results. The causes for the differences are identified, the records are grouped into causes, and we get the results in the following format:

Numerical discrepancies:

  • 5 percent of records could not boot due to a functional defect 1
  • 3.5 percent of records could not be loaded due to a functional defect 2
  • 1 percent of records could not boot due to a functional defect 3
  • 0.5 percent of records could not be loaded due to a functional defect 4

Discrepancies in the amount of write-offs:

  • 7 percent of records are processed improperly because of a defect in the configuration No. 5
  • 1 percent of records are processed improperly because of a defect in the configuration No. 5
  • 0.5 percent of records processed improperly because of a defect in the configuration  No. 5
  • 0.1 percent of records processed improperly because of a defect in the configuration No. 5

What is the outcome of this approach?

  1. It provides complete coverage of the product catalog, through the activities of real users. The system tests exactly what is used by subscribers;
  2. It checks the quality of the configuration and system migration, as well as the most critical functionality for OSS/BSS parts: rating, billing and payments;
  3. It helps clearly prioritize defects that are present in the system based on the needs of the business. Let’s say, it is more important to correct defect No. 1, compared to defects No. 3 or No. 4, since defect No. 1 does more damage to the business;
  4. Because testing takes place on a large volume of data, this is a good way to test how well the new version of the system can withstand real-world loading.

Of course, there are limitations to this approach.

First, the data comparison is always dependent on what type of OSS/BSS you use. It will be necessary to develop a unique script for your system to compare and select data to analyze. Second, in the ideal case, the test environment must comply with the product environment. Otherwise, there is a risk that you won’t meet the deadline because the test environment processes transactions too slowly.

Рейтинг
( Пока оценок нет )
Editor
Editor/ автор статьи

Давно интересуюсь темой. Мне нравится писать о том, в чём разбираюсь.

Понравилась статья? Поделиться с друзьями:
Центр Начало
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: