Sistemas de Gestión

Dada la complejidad y tamaño que suelen tener las redes de telecomunicación de una Operadora, es imposible plantearse realizar manualmente todas las operaciones de gestión que se necesitan, por tanto se hace necesario disponer de sistemas informáticos que automaticen la gestión de dicha red. Estos sistemas se denominan de forma genérica Sistemas de Gestión (Management Systems), e incluso disponen de una red de comunicaciones propia (red de gestión) superpuesta a la red de telecomunicaciones que se pretende gestionar.

Por el volumen de datos a gestionar y de funcionalidades a manejar en una Operadora no existirá uno, sino que se necesitarán varios sistemas de gestión. En un caso genérico podríamos hablar de decenas de sistemas. Cada uno de ellos estará especializado en uno o varios de los procesos que hemos comentado en los apartados anteriores.

Es en este contexto en el que debemos introducir el importante concepto de Mapa de Sistemas. La definición de este mapa sería el conjunto de documentación que proporciona la visión global de todos los sistemas que existen en la Operadora. Es muy importante, que en una compañía, este mapa esté definido al máximo nivel de detalle posible, pues de esta manera se lograrán evitar posibles solapamientos o carencias de funcionalidad. La definición del mapa debe incluir:

diagramas con todos los sistemas, sus interacciones,

sus interfaces,

los datos que intercambian,

las funcionalidades que soporta cada sistema,

El TMForum realiza también una clasificación formal de las funcionalidades o aplicaciones que pueden existir en los sistemas de una operadora de telecomunicación. Esta clasificación se denomina TAM “Telecom Applications Map” (Mapa de Aplicaciones de Telecomunicación) y sirve como un marco de referencia que ayuda a clasificar los sistemas que podemos encontrarnos. De la misma manera que el eTOM define procesos, podríamos decir que el TAM define sistemas reconocibles, sobre los cuales se implementarán dichos procesos. Evidentemente existe un mapeo bastante obvio entre aplicaciones del TAM y procesos eTOM, concretamente con los procesos de nivel 2 de detalle (usan nombres muy parecidos e incluso a veces los mismos).

Figura 22: TAM. Mapa de Aplicaciones de Telecomunicación 2.6.1. Integración de sistemas

Aunque en una Operadora existan varios sistemas de gestión, éstos no pueden funcionar de manera totalmente independiente. Es necesario que se interrelacionen entre ellos. En el fondo, la red y los servicios que gestionan son los mismos para todos los sistemas. Será habitual que compartan datos (que pueden residir en la misma base de datos o replicarse de unos sistemas a otros). En definitiva, siempre surgen la necesidad de una integración de los sistemas.

A veces la necesidad de integración surge entre sistemas ya existentes. Otras veces aparece cuando se trata de implantar un nuevo sistema, dentro de un mapa de sistemas, y el nuevo debe colaborar con los demás.

También podríamos englobar aquí las tareas de configuración de paquetes de software comerciales que se pretendan instalar como un nuevo sistema. Es decir, no siempre hablamos de desarrollos a medida, sino que también de productos comerciales que tras ciertas adaptaciones y configuraciones son instalados en la operadora.

La tarea de integración de sistemas es muy compleja y es una de las que más coste genera dentro de una compañía. Además es una tarea que inevitablemente hay que afrontar. Continuamente las redes evolucionan, también aparecen servicios nuevos, y todas estas novedades demandan nuevos sistemas que las gestionen.

Hay que tener en cuenta que, a no ser que tengamos una compañía Operadora que se acaba de crear, no se puede partir de cero. Cada vez que deseemos instalar un sistema nuevo se deberá integrar con sistemas ya existentes, pudiéndose encontrar un escenario de los más variopinto. Algunos de esos sistemas existentes serán mucho más antiguos, otros construidos con tecnologías diferentes, otros pueden tener datos o funcionalidades similares con las que hay que convivir, pueden tener complejas restricciones de funcionamiento o de interconexión, etc.

El problema de la integración de las diferentes bases de datos de los sistemas se trata, más adelante, en un apartado exclusivo dedicado a ello.

2.6.2. Claves para una integración con éxito

Aparte de lo evidente, disponer de presupuesto y tiempo, son destacables las siguientes claves para el éxito de esta tarea:

Sistemas documentados:

En una compañía Operadora, todos y cada uno de los sistemas de gestión que se tengan deben disponer de una buena y detallada documentación, la cual debe incluir información de arquitectura (tanto software como hardware), descripción del modelo de sus bases de datos, interfaces internas, interfaces externas (incluyendo interfaces gráficas de usuario), funcionalidad detallada, etc.

Esto incluye también a los productos comerciales. Cuando se pretenda instalar un producto o una suite de productos software comerciales que necesiten cierta configuración, es necesario conocer el máximo detalle del producto. El fabricante debe proporcionar información detallada de funcionalidad, arquitectura, necesidades de hardware, limitaciones, restricciones de funcionamiento, escalabilidad, capacidad de procesamiento, interfaces, etc. Incluso a veces lo más útil es poder contar con un asesor experto que tenga un conocimiento profundo del producto.

Visión Global:

Lo habitual es que cada uno de los sistemas instalados haya sido desarrollado por una empresa diferente (buscando un ahorro de costes, tras haber organizado un concurso para el cumplimiento de

una serie de requisitos). Esto quiere decir que cada sistema habrá sido documentado por separado por cada empresa desarrolladora.

Sin embargo esto no es suficiente. Es necesario disponer de una documentación de conjunto que proporcione una visión global de todos los sistemas. Una documentación que detalle el mapa de sistemas existente, con el papel de cada sistema en los procesos de la operadora, sus interrelaciones y dependencias. Esta documentación debe ser elaborada por el personal de la operadora, ya que los expertos de cada sistema particular sólo suelen tener la visión parcial de su propio sistema y nada más.

Sólo basándose en esa documentación global de conjunto es posible diseñar nuevos sistemas pensando en la manera en la que encajarán en los procesos de negocio, y colaborarán con los sistemas ya implantados.

Interlocutores válidos:

Una buena documentación, tanto de los sistemas individuales como de su funcionamiento conjunto, es necesaria pero no suficiente para garantizar un proyecto de integración. Para integrar un nuevo sistema es necesario realizar documentación detallada del mismo y organizar reuniones para intercambiar esa información y llegar a acuerdos sobre las interconexiones y colaboraciones con los sistemas existentes. En estas reuniones hay que contar con interlocutores válidos que en conjunto cumplan estas condiciones:

- Posean conocimiento detallado de los sistemas involucrados en la integración. - Posean conocimiento de los procesos globales de la operadora.

- Tengan poder de decisión para ordenar la ejecución de los acuerdos tomados.

Sin cumplir estas condiciones las negociaciones se eternizan: las reuniones son improductivas por desconocimiento técnico de los asistentes, se repiten muchas veces las mismas cosas por rotación de los interlocutores de los sistemas, se malentienden los acuerdos por no profundizar en los detalles, o se llega a acuerdos que luego no se ejecutan por no tener poder de ordenar una implementación. La consecuencia de todo esto será con toda seguridad un incumplimiento de los plazos del proyecto y un sobrecoste sobre la cantidad inicial presupuestada.

Encontrar e identificar estos interlocutores válidos no es fácil. Tanto es así que muchas veces es necesario contratar consultores externos a la compañía, que sean realmente imparciales, se estudien a fondo todos los sistemas y procesos, y sean dotados con el poder de imponer soluciones a todos los participantes en la integración.

Cubrir todos los aspectos:

No basta con llegar a acuerdos de alto nivel, sino que hay que bajar al detalle de cada uno de los aspectos de la integración:

- Aspectos funcionales: funcionalidades de los sistemas e interfaces entre ellos (con todo el detalle de mensajes, campos y valores de los mismos).

- Aspectos de rendimiento de las soluciones: más allá de la funcionalidad es necesario estudiar el rendimiento. Es posible que un proceso tenga un buen diseño funcional, que su lógica sea perfecta cubriendo toda una serie de casuísticas, pero puede ocurrir que al ejecutar decenas de instancias de dicho proceso en paralelo, cargue tanto las máquinas que sea imposible de ejecutarse.

- Aspectos de arquitectura: arquitectura hardware y software.

Impacto en procedimientos manuales:

En la mayoría de los sistemas todavía existen tareas que se deben realizar manualmente o que deben ser atendidas por un operador humano. Sobre todo las relativas al tratamiento de excepciones o funcionamientos anómalos.

En una integración de un sistema nuevo es necesario describir al detalle cómo se va a usar el sistema y, adicionalmente, cómo va a cambiar el uso del resto de sistemas con los que se relaciona. Debe generarse una buena documentación de los procedimientos manuales y programar una formación, sobre esos procedimientos, a todos los operadores que se vayan a encargar de esa tarea. No debe quedar nada al azar, puesto que los procedimientos manuales van a ser una de las mayores causas de errores en los procesos. No debe dudarse en invertir esfuerzo para conseguir buenas guías de actuación, en los procedimientos manuales, para todas las casuísticas que se le puedan presentar al operador.

Voluntad de integración:

Todo lo anterior no servirá de nada si no hay voluntad, por parte de los responsables de los sistemas implicados, de integrarlos. Correos sin respuesta, reuniones improductivas, acuerdos que no se cumplen, fechas que se retrasan, etc., serían claros síntomas que no hay voluntad de llegar a un acuerdo productivo. Es probable que alguno de los implicados no esté interesado en la integración porque, por ejemplo, suponga una reducción de funcionalidades en el sistema bajo su cargo, y por tanto una reducción de su presupuesto. En esos casos es necesaria una decisión ejecutiva de algún jefe superior o directivo que desbloquee la situación.