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

 

Тенденции в телекоммуникационной индустрии меняют требования к системам OSS и BSS

 

Движение маятника не останавливается, поскольку у каждого подхода имеются свои достоинства и недостатки. К примеру, управление отклонениями транзакций – проблема, с которой сегодня сталкиваются многие крупные операторы. Лучшие в своем классе подходы, с учетом микросервисов, обеспечивают клиентам гибкость в проектировании. Однако, с другой стороны, модульность приводит к увеличению количества точек интеграции. Именно в этих точках интеграции часто происходят сбои – при передаче протоколов из одной системы в другую и обратно.

 

Речь идет не только об отклонениях транзакций. Увеличение количества точек интеграции имеет и другие последствия:

 

  1. Стоимость интеграции, интеграционные издержки, как правило, увеличиваются. Необходимо добавить уровень адаптации при соединении одной системы с другой.
  2. Интеграция систем – мысль, приходящая задним числом. Не в том смысле, что об интеграции как таковой думать поздно. Разработчики редко учитывают специальную интеграцию «Продукта А» и «Продукта В» / «С» и т.д., в связи с чем интеграторам может понадобиться одновременно перековывать различные модели данных, со всеми возможными ошибками их несоответствий. Так, две интегрированные системы с общим атрибутом могут иметь несходные форматы или соглашения по именованию объектов баз данных.
  3. Два поставщика, изолированно проектирующие модели данных для своих продуктов, не учитывают интенсивность кросс-линейных связей данных. Если для работы интерфейса связей может быть достаточно, то для бесперебойной поддержки объемного анализа данных – уже нет.
  4. Для обеспечения надежной работы интерфейса по всем возможным сценариям требуется дополнительный анализ. Это означает проверку наборов данных, их форматов, процессов и протоколов. К сожалению, в том случае, если анализ не охватил всех возможных сценариев, случаются отклонения транзакций.

 

Наличие тесно связанных сквозных решений позволяет справиться с многими из этих проблем.

В качестве примера рассмотрим сценарий заказа к активации (Order to Activation, или O2A). Идеальный вариант, когда есть решение, управляющее протоколами O2A от:

 

  • регистрации клиента
  • к вводу заказа на услугу,
  • к управлению рабочими процессами,
  • к проектированию сети и поддержки обслуживания,
  • к распределению ресурсов / инвентаризации / услуг / рабочих ресурсов,
  • к активации услуги / инициализации (сетевой и системной конфигурации),
  • к заключительной синхронизации по результатам внедрения.

 

Многие из вышеупомянутых проблем позволяет преодолеть наличие решения от одного поставщика, такого как SunVizion, с предварительно интегрированными инструментами, в состав которых входят:

 

В SunVizion предварительная интеграция данных функций означает следующее:

 

  1. Встроенный уровень адаптации.
  2. Большая согласованность моделей данных, разрабатываемых в комплексе.
  3. Широкая кросс-линейная связь данных как неотъемлемая часть системы.
  4. Усовершенствования и оптимизация как результат анализа множества проектов и клиентов на протяжении многих лет.

 

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

 

Междоменные запросы обеспечивают ряд наиболее ценных ответов по вашим данным. Однако для выполнения междоменного запроса вам понадобится набор данных c широкими кросс-линейными связями. К примеру, если ваш отдел маркетинга хочет знать, кому адресовать промо-акции, вы можете запросить:

 

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

 

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

 

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

 

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