Una visión de Gartner Group acerca del Efecto 2000

Con una bomba de tiempo virtual marcando los segundos en mainframes en todo el mundo, muchos directores de sistemas de información deberán enfrentarse a algunos problemas graves antes de celebrar la llegada del año 2000.

Casi todo el mundo está esperando la celebración del nuevo año el 1 de enero del año 2000. Después de todo, no será un año nuevo como otro cualquiera y ni siquiera significará el paso de un nuevo siglo. En un plazo de sólo cuatro años tendrá lugar el nacimiento de un nuevo milenio. Y sin embargo, muchos directores de sistemas de información en todo el mundo están aplazando por tiempo indefinido las celebraciones. Para ellos, el primer día de ese nuevo milenio aparece en el horizonte como una fecha de desastre.

El motivo de esta actitud poco festiva son dos pequeños dígitos que están causando un enorme problema.

Según el Gartner Group, esta bomba de tiempo prevista para explotar en el año 2000 es uno de los problemas clave a los que se enfrentarán los directores de sistemas de información y sus organizaciones durante los próximos años. Gartner Group considera que una compañía de tipo medio-grande tiene 8.000 programas antiguos ya existentes soportando operaciones comerciales. Estos programas contienen generalmente un total de 12 millones de líneas de código. Como por término medio una de cada 50 líneas de código contiene a su vez una referencia de fecha, aproximadamente 240.000 líneas de código requerirían modificación. A un costo estimado de entre 30 y 40 centavos por línea de codificación sólo para costos de programación, una compañía puede esperar un gasto de entre 3,6 millones y 4,8 millones de dólares para resolver el problema. Y esto no incluye siquiera los costes de documentación, tests de integración de sistemas y gestión del proyecto, que en algunos casos podrían hacer que el coste se acercara más a un dolar por línea de código.

En total, se prevé que remediar la situación costará entre 300.000 y 600.000 millones de dólares, según el Gartner Group. Para una empresa u organización típica, esto podría representar entre un 5 y un 10 por ciento de su presupuesto informático anual en el curso de los próximos años. Algunas empresas que tuvieron la suerte de conseguir una ventaja de salida para el problema, pudieron distribuir en varios años el coste de convertir sus datos y aplicaciones. Sin embargo, Gartner señala que el coste de la conversión de los sistemas podría significar la quiebra de cierto número de compañías ya inestables financieramente.

Asumir el problema

Una cosa que hace que la situación resulte incluso más peligrosa para muchos directores de sistemas de información es el hecho de que por lo general el problema no está cubierto en los contratos que mantienen las empresas con los proveedores de outsourcing. Como consecuencia, los directores de sistemas de información que habían asumido que un contrato a precio fijo les protegía frente a algo como el problema del próximo milenio se enfrentan a un rudo despertar.

¿Cómo se ha llegado a esta situación? A mediados de la década de los años 60, durante el auge del mainframe, fueron muy pocos los que prestaron atención al problema del año 2000. Para empezar, el espacio de almacenamiento era tan precioso como el oro, y el concepto de ahorrar dos dígitos en miles o incluso millones de registros de bases de datos parecía una gran idea. Por lo tanto, ¿qué importaba si a largo plazo iban a surgir problemas? Era mejor dejar que el sucesor se enfrentara a ellos mientras uno disfrutaba tranquilamente de la jubilación.

Muchos de esos sucesores manifiestan ahora su indignación frente a quienes les precedieron, lo cual no contribuye en nada a resolver el problema. Lo mismo que en muchas otras situaciones, el primer paso para desactivar esta bomba de tiempo es reconocer que el problema existe. Muchos directores de sistemas de información, temerosos del coste que supone la resolución del problema, esperarán hasta el último minuto antes de alertar al resto de la dirección de la empresa sobre ese peligro inminente. Y sin embargo, la espera sólo empeora la situación. Es como el animal que queda inmóvil en la carretera ante los faros de un coche.

Además de modificar o sustituir el software de aplicación, también habrá que corregir en muchos casos millones de registros de datos con el fin de adaptarlos al programa actualizado. Es un problema de gran alcance; no sólo hay que examinar registros de base de datos, sino también el software de sistema, los sistemas operativos, los paquetes, las hojas de cálculo, etcétera."

Pasos a seguir

El primer paso para delimitar y resolver el Efecto 2000 es realizar un inventario a fondo de todos los sistemas. Este proceso largo y laborioso requiere analizar todas las aplicaciones y bases de datos de la empresa en busca de fuentes potenciales de problemas. Cada empresa se enfrenta a un escenario único y específico. Algunas tendrán suerte si salen libradas con sólo unas fechas incumplidas en los pagos, mientras que otras podrían sufrir el colapso de todo su sistema de contabilidad. Son pocas las que han detectado y corregido el problema hace tiempo.

Un director de sistemas de información que actúe inteligentemente puede convertir la bomba de tiempo de un problema enorme a una oportunidad enorme, según la consultora Andersen Consulting. Puede aprovecharse la crisis que se avecina, uno de los esfuerzos de mantenimiento más importantes a los que se enfrentará cualquier empresa, convirtiéndola en parte de una estrategia de Sistemas a largo plazo. Hay que analizar las oportunidades para determinar cómo convertir la crisis de una fuga de recursos a algo más valioso. Significaría tener muy poca visión si se ampliara el campo de fecha sin atender a otras carencias detectadas por un análisis adecuado. El departamento informático podría decidir realizar un nuevo trabajo de desarrollo, migrar a otra plataforma, detectar la necesidad de mejorar el mantenimiento o crear una aplicación completamente nueva.

No obstante, la simple inclusión de nueva tecnología no permitirá necesariamente a una empresa eludir la cuestión de la bomba de tiempo. Por ejemplo, migrar software mainframe antiguo a una red cliente/servidor no es en sí mismo una mala idea, pero en este caso se trata de una tarea importante y, además, se corre el riesgo de simplemente trasladar el problema de un entorno a otro.