Cuando uno tiene varios años de experiencia en la industria de telecomunicaciones, empieza a notar que las tendencias OSS/BSS son como un péndulo. El péndulo que, en este caso, se mueve desde los productos estandarizados y comerciales hasta los desarrollados internamente, y regresa; desde lo monolítico hasta lo modular, y vuelve. La tendencia actual indica el alejamiento de las pilas monolíticas a favor de los microservicios. Durante años, las grandes empresas de telecomunicaciones han fomentado la modularidad, optando por las soluciones óptimas disponibles en el mercado. Al día de hoy, sin embargo, están haciéndose cade vez más con los microservicios que reflejan la modularidad, pero a microescala.

Tendencias en la industria de telecomunicaciones están modificando los requisitos de sistemas OSS y BSS

 

El péndulo va y viene, ya que cada aproximación tiene diferentes ventajas y puntos débiles. Para dar un ejemplo: un desafío común al que se enfrentan muchas grandes empresas de telecomunicación es la gestión de fallos. Optar por las soluciones óptimas del mercado y los microservicios presta a los consumidores la flexibilidad de diseño. Sin embargo, la modularidad provoca un mayor número de puntos de integración. Es ahí donde a menudo ocurren fallos, cuando las transacciones traspasan y vuelven de un sistema al siguiente.

 

Tampoco se trata únicamente de fallos; un número elevado de puntos de integración aporta también otros contextos:

 

  1. El costo de integración, o “el impuesto de integración”, tiende a aumentar. Se precisa de una capa de adaptación al conectar un sistema al otro.
  2. La integración entre sistemas es una ocurrencia tardía. No quiere decir eso que la integración como tal es una ocurrencia tardía: es la integración específica del producto A y producto B/C/etc., pocas veces tomada en cuenta por los developers. Los integradores pueden tener que hacinar diferentes modelos de datos, con las posibles desalineaciones como resultado. Puede que, p.ej. dos sistemas integrados compartan uno u otro atributo, pero de diferentes formatos o nomenclaturas.
  3. Cuando dos proveedores diseñan los modelos de datos para sus productos de manera independiente, no lo hacen precisamente con las múltiples interrelaciones de datos en mente. Puede haber suficiente correlación para que la interfaz funcione, pero no para dar apoyo fiable a un integral análisis de datos.
  4. Se requieren pruebas adicionales para garantizar que la interfaz funcione sin problemas en todos los escenarios posibles, lo que significa la necesidad de probar los conjuntos de datos, sus formatos, procesos y transacciones. Desafortunadamente, los fallos ocurren cuando las pruebas no han podido tomar en cuenta todos los escenarios posibles.

 

Tener una solución estrechamente conectada end-to-end elimina la gran parte de estos desafíos.

Miremos, por ejemplo, el escenario de la orden-a-activación (O2A). Lo óptimo es que exista una solución que maneje las transacciones O2A desde:

 

  • integración de cliente a
  • entrada de orden de servicio a
  • gestión de flujo de trabajo a
  • diseño de redes y servicios a
  • asignación de recursos / inventario / servicio / mano de obra a
  • activación / aprovisionamiento de servicios (configuración de red y sistema) a
  • reconciliación post-implementación.

 

Tener la solución de un solo proveedor, como SunVizion, con las herramientas preintegradas como las que se enumeran abajo, supera muchos de los retos anteriormente mencionados:

 

En el caso de SunVizion, la preintegración de estas funciones significa que:

 

  1. Las capas de adaptación ya vienen integradas
  2. Los modelos de datos son más coherentes al haber sido desarrollados juntos
  3. La mayor interconexión de datos es inherente
  4. Las pruebas han abarcado muchos proyectos y muchos clientes. Esto ha permitido ajustarlo y mejorarlo durante el curso de varios años.

 

A menudo se pasa por alto del punto 3 de la lista anterior, a la hora de planificar un proyecto OSS/BSS. La mayoría de las herramientas OSS/BSS ya incorpora potentes herramientas de generación de información dentro de sus respectivos dominios. Por ejemplo, el inventario de red de cada proveedor permite que los usuarios puedan encontrar la capacidad, reservar los recursos, rastrear los servicios o circuitos a través de la red y ejecutar muchas otras funciones importantes.

 

Las consultas entre dominios proporcionan algunas de las respuestas de mayor valor que pueda obtener a partir de los datos en su posesión. Pero cuando uno quiere realizar una consulta entre dominios, precisa de un conjunto de datos que esté fuertemente interrelacionado. Por ejemplo, si su equipo de marketing desea saber a quién enviarle las ofertas, usted puede preguntar:

 

  • Qué casas están a 500m de la nueva sección de la red que usted está construyendo
  • Dentro de un determinado suburbio o código postal
  • Aún no son clientes activos
  • Y luego discriminar entre los domicilios que hayan solicitado una cotización y aquellos que no la hayan solicitado hasta la fecha, o
  • Fueron conectados anteriormente, o no

 

Para que esto sea posible, los conjuntos de datos tienen que estar entrelazados en el inventario, la planificación de redes, la gestión de órdenes de servicio y el CRM.

 

Será más bien difícil responder a las preguntas entre dominios si las integraciones OSS/BSS y los datos no están estrechamente interconectados. Es sumamente más fácil hacerlo cuando la pila O2A viene construida por una empresa, end-to-end, como es el caso de SunVizion.

 

Tener los datos de la red y los clientes disponibles en un solo lugar, dentro de una base de datos interrelacionados, facilita la preparación de consultas complejas mediante las típicas herramientas de inteligencia comercial. Así se libera una gran cantidad de información, normalmente atrapada dentro del área de operaciones, y se la pone a disposición de otras unidades comerciales en su empresa.