Año 2000: odisea en el CPD

Cuando cambie la fecha en el año 2000, se producirán enormes alteraciones en los sistemas informáticos, con el consiguiente descontrol en los cálculos. Sin embargo, pocas compañías están afrontando el problema. ¿Está usted preparado?

Soy un idealista. Esto puede ser un problema o un punto a favor. Significa que me gusta la exactitud; no "lo más exacto posible", sino "totalmente exacto". No me gusta la ambigüedad, y no me gusta el riesgo innecesario, especialmente el riesgo con consecuencias desconocidas y muy negativas. ¿Es extraño entonces que me haya obsesionado con el problema de la fecha del Año 2000?

En pocas palabras: la mayoría de las aplicaciones almacenan los datos del año en forma de dos dígitos. Nuestros sistemas asumen que estos dos dígitos (por ejemplo, 34) van precedidos de 19 (por ejemplo, 1934). Cuando en el año 2000 el año se convierta en 00, la mayoría de las aplicaciones asumirán que se trata de la fecha 1900, dando lugar a fallos del sistema e informes no válidos.

En base a conversaciones con cientos de compañías, consultores y vendedores, he llegado a la conclusión de que menos de un 20% de las empresas y organizaciones de todo el mundo están afrontando el problema de la fecha del Año 2000. Y la mayoría de ellas sólo se encuentran en las etapas iniciales de la planificación.

Resolver el problema significa en realidad un ejercicio de poca importancia para cualquier programador.

Consiste, simplemente, en ampliar el año en dos dígitos o ampliar el campo de fecha para incluir un campo/señal de siglo o utilizar lógica de fechas.

Los programadores necesitan también tener en cuenta que el año 2000 es bisiesto. De lo contrario, después del 28 de Febrero del año 2000, las aplicaciones no sabrán cuál es el día de la semana.

Sin embargo, muchas compañías tienen más de 50 millones de líneas de código en las que deben buscar para localizar estos problemas de fechas, y quedan cada vez menos días para enfrentarse a lo que es en realidad una bomba de relojería.

Si asumimos que se requerirá un segundo por cada línea de aplicación para corregir, probar e implementar el cambio, y se trabajan ocho horas al día, cinco días a la semana, 50 semanas al año, revisar esos 50 millones de líneas de código será un trabajo de aproximadamente siete años (Si, ya sé que es una forma algo absurda de afrontar el proyecto, pero es algo para comenzar).

¿Qué hacer primero? ¿Qué dependencias existen entre los sistemas? ¿Cuándo estará disponible software de los vendedores para comunicar con los sistemas modificados? ¿Cómo modificarán su software los vendedores? ¿Puede uno comenzar antes de que ellos acaben? Este es el mayor desafío de gestión de proyecto en que usted intervendrá, y requerirá los controles más estrechos que pueda poner en práctica, ya que la fecha límite no se aplazará.

Esta obsesión mía ha dado lugar a que se me asignen algunos nombres, como "el Casandra digital", "Quejica del Milenio", "Profeta de Catástrofes", etc. Algunos prefieren matar al mensajero... Así es la vida.

Pero el problema es real. IBM lo expresa de forma simple: "Es imperativo que los clientes realicen el upgrade de todo su software, sistemas operativos y aplicaciones, a las versiones actuales. De lo contrario, podrían tener problemas a partir del 1 de enero del 2000".

El problema de la fecha no está afectando sólo a los mainframes. Intente este test en su PC: fije la fecha y la hora al 31 de diciembre de 1999, a las 23:57. Espere cinco minutos. Póngalo en marcha. Compruebe la fecha. ¿Es el 4 de enero de 1994? De cualquier forma, probablemente no será el 1 de enero del 2000.

A menos que resuelva el problema, su ordenador personal quedará prácticamente inutilizado el 1 de enero del 2000. Y, exactamente, lo mismo sucederá con las aplicaciones. El 1 de enero del 2000 serán prácticamente inútiles. A menos, naturalmente, que las arregle.

En la mayoría de los sistemas, el problema es que no sabemos cuándo, cómo o si fallarán en el año 2000, pero no podemos permitirnos no saberlo. ¿Es aceptable el riesgo de no poder crear facturas?

Los dos dígitos faltantes tienen implicaciones que van más allá de las simplemente técnicas. A pesar de que su origen está en los bits y los bytes de las aplicaciones, el problema es y ha sido siempre un problema comercial.

Los programadores saben perfectamente que la codificación puede fallar, los analistas saben que los programas pueden fallar, y los directores en las empresas saben que las aplicaciones pueden fallar, y el efecto que estos fallos pueden tener sobre la actividad comercial de una determinada entidad.

Saber todo esto, y no actuar en la forma adecuada, o más bien no estar preparado para hacerlo, es una grave negligencia. Los profesionales de sistemas de información tienen algo más que una simple responsabilidad de informar a la Dirección General de su empresa. Como profesionales, tienen la obligación moral de convencer a los directivos de la magnitud del problema, y rectificarlo. Los riesgos comerciales están enraizados en la base técnica misma de la organización. Usted ha creado esa base, comprende cómo todo sistema de información complejo puede fallar en algún momento a causa de componentes faltantes o defectuosos, y comprende la verdad de que la falta o carencia de cualquier pequeño elemento puede significar, y de hecho significa, la pérdida de toda una empresa.

Algunas compañías están actuando ya

Sólo un 20% de las compañías están afrontando actualmente el problema del cambio de fecha en el año 2000. La mayoría de estas compañías de primera línea se encuentran en las etapas iniciales para la resolución del problema, y están dándolo a conocer cada vez más, evaluando qué sistemas se verán afectados y planificando un curso de acción. Pocas han comenzado en realidad a manipular el código de sus aplicaciones.

Social Security Administration (Estados Unidos). La SSA (Social Security Administration), en Washington, inició su proyecto en 1989 como parte de las actividades de mantenimiento normales, cuando sufrió un fallo relacionado con la fecha en su aplicación de recuperación de deudas. Desde entonces, esta agencia del gobierno ha introducido cambios en las fechas como parte de su actividad de mantenimiento normal.

GTE Corp. La firma GTE no ha permanecido inactiva tampoco respecto a la cuestión del año 2000. En esta firma se piensa que el soporte a la gestión y la planificación son de importancia clave para reducir el riesgo a cero. Con este fin, GTE publicó una serie de normas indicando que todas las localizaciones GTE deberán disponer de un plan de conversión de fechas perfectamente definido y gestionable, en condiciones de funcionamiento para el 1 de abril de este año. El plan requiere que todos los cambios al software y las modificaciones operacionales estén realizados el día 31 de Diciembre de 1998. GTE comenzó a preocuparse por los riesgos a finales de 1993, cuando el personal técnico informó sobre los problemas relativos a las fechas. Como consecuencia de ello, pusieron en circulación en 1994 un Libro Blanco detallando la naturaleza, alcance, posibles impactos y soluciones.

Problema sencillo, solución difícil

El problema de la fecha en el Año 2000 es "fácil de comprender, pero la solución es bastante difícil y desagradable," afirma la consultora Gartner Group. En su opinión, incluso con la variedad de herramientas automatizadas disponibles, las compañías deberán realizar una gran cantidad de trabajo manual. Los programas sin código fuente, o aquellos cuyos cambios de año estén fijos, resultan particularmente espinosos. Algunos analistas definen los problemas del Año 2000 como "una crisis sin precedentes en el sector informático", por tres motivos:

- Por primera vez hasta ahora, esto es algo que hay que hacer, a dif