Tiempo de desarrollo

Cada vez más, la implementación de grandes sistemas de telecomunicación en las empresas tiene que hacerse lo más rápido posible. Los nuevos servicios de telecomunicación aparecen muy rápido, y la presión de la competencia hace que sea crítico minimizar el tiempo que se tarda en sacar al mercado cada nuevo servicio. También aparecen rápido nuevos equipos de red, que realizan las tareas para las que están diseñados mucho más rápido que otros equipos antiguos, y por tanto surge la necesidad de integrarlos lo más pronto posible dentro de los sistemas de gestión que tenga nuestra compañía Operadora.

Esta gran dinámica que existe en el mundo de la telecomunicación obliga a los sistemas de gestión a tener que estar continuamente adaptándose. Esto es una diferencia con otros sectores, como por ejemplo, la Banca, en la que sí es posible que vayan apareciendo nuevos productos financieros, pero en el fondo los sistemas de gestión, simplificándolo mucho, suelen tener una gran componente de base de datos y lo único que hay que cambiar es el modelo de datos para acomodar esos nuevos productos.

¿Qué significa esto? Pues que la época de los proyectos de desarrollo faraónicos, planificados con un horizonte de plazo de desarrollo de varios años, ha acabado. Ahora mismo, los proyectos de desarrollo de sistemas de gestión deben ser proyectos a muy corto plazo, con una rápida puesta en producción, de manera que satisfagan las demandas cambiantes y variables que van apareciendo. Si el desarrollo no llega a tiempo, y empieza a demorarse su puesta en producción, debido a fallos que no acaban de solucionarse, ya no servirá para nada. Es muy probable que la competencia nos haya ganado la partida y esté captando los clientes de ese nuevo servicio o producto, que nuestra Operadora no ha podido captar.

Evidentemente no es estrictamente necesario un completo sistema de gestión para poder vender al cliente final un nuevo servicio de telecomunicación. Siempre pueden adoptarse soluciones de contingencia, aumentando la cantidad de acciones o actividades manuales en los procesos de gestión. Así, en lugar de tener un sistema automático que reciba la petición comercial de provisión del servicio y lleve a cabo su activación en los elementos de red, podríamos tener un equipo humano de técnicos, que reciban las solicitudes de provisión con todos los datos y que sean ellos los que actúen de activadores manuales. Para ello podrían entrar directamente en las consolas de los equipos para ejecutar la secuencia de comandos de activación necesarios para cada provisión. Y luego, los mismos técnicos, podrían registrar mediante algún procedimiento asistido, la información de los servicios provisionados a los clientes, en el inventario del sistema.

Soluciones de contingencia como las explicadas aquí pueden tener su utilidad cuando la previsión de demanda de un nuevo servicio no sea muy grande. Pero si no es así, y la previsión es que el servicio va a ser muy demandado, la capacidad de procesamiento de órdenes de provisión con un método manual es muy pequeña comparada con un sistema automático de gestión.

Un ejemplo actual de nuevos servicios y nuevas redes lo constituye el despliegue de las redes de acceso de banda ancha con tecnología GPON (Gigabit-capable Passive Optical Network). Todas las operadoras, a lo largo de todo el mundo, están desplegando estas redes pues permiten la posibilidad de llevar nuevos servicios de banda ancha a los hogares, con velocidades binarias muy superiores a las actuales redes de acceso. El despliegue de estas redes es estratégico pues son la puerta para servicios por los cuales las operadoras van a poder ingresar grandes cantidades de dinero en el futuro cercano. Los clientes demandan cada vez más mayores velocidades de transmisión, y eso es lo que aportan estas redes ópticas. El despliegue de la tecnología GPON supone nuevos elementos de red que deben ser gestionados, lo cual significa:

Adaptar los modelos de datos de los inventarios para dar cabida a estos nuevos equipos.

Cambiar las funcionalidades de supervisión para poder captar sus nuevas alarmas o las nuevas medidas que proporcionen.

Adaptación de procesos a las particularidades de gestión que tengan. Etc.

Dicho en pocas palabras, todo esto supone que deben ser integrados en los sistemas de gestión de la operadora. Esto significa cambiar los sistemas, y cambiarlos rápido pues de lo contrario las empresas de la competencia se quedarán con nuestros clientes potenciales.

Lidiar con este entorno dinámico y cambiante obliga a prestar una especial atención a los diseños de los sistemas. Hoy en día cobra una especial importancia que el diseño de un sistema no se haga solamente pensando en las funcionalidades actuales que de él se requieren, sino que el diseñador se debe proyectar más allá, con una previsión de las posibles funcionalidades futuras y del volumen futuro de información que deba manejar.

Los diseños deben ser flexibles y adaptables. La aparición de un nuevo servicio o de un nuevo elemento de red no debe suponer un gran tiempo de desarrollo para integrarlo en el sistema, por todas las razones que se han comentado anteriormente. La base de datos y las funcionalidades que operan sobre ella, deben haber sido pensadas para esas posibles extensiones.

El sistema también debe ser escalable, es decir, tener la capacidad de poder ser adaptado de forma rápida a un aumento del volumen de los datos o de las operaciones que deba soportar. Aunque en la primera implantación del sistema, recién desarrollado, no tuviera unos grandes requisitos de volumen de datos o de transacciones, debe haberse pensado en el futuro, y debería ser fácilmente expandible mediante la adición de módulos hardware o adquiriendo más licencias de los productos de software comercial que se usen (si ese el caso). El diseño debe huir de los “cuello de botella” para permitir esta escalabilidad. Si no se ha hecho con cuidado podríamos encontrarnos con una tabla de la base de datos que, por ejemplo, sea muy consultada y no está suficientemente dimensionada, o que posea un dato que es frecuentemente modificado y a su vez la tabla sea muy accedida para consultas, o tener consultas que recopilen información de varias tablas, y que por el hecho de no estar optimizadas tengan un tiempo de ejecución demasiado lento.

Es inevitable que, ante la aparición de nuevos requisitos para el sistema, debamos replantear u optimizar algunas cosas en el mismo, pero el objetivo es que estas sean las mínimas posibles. Aunque no exista solicitud o necesidad de nuevos requisitos, es una buena práctica el no dejar de optimar el sistema, repasando sus puntos débiles y mejorando continuamente sus prestaciones. Así cuando llegue la necesidad real de una nueva funcionalidad, el sistema se encontrará mejor preparado, y se podrá dar una respuesta rápida al cliente (entendiendo por cliente, la persona o departamento de la que surge la necesidad del nuevo requisito).