Efecto 2000: cómo gestionar íntegramente el proceso de cambio

En los primeros años de la informatización, incluso antes del lenguaje COBOL, el espacio de almacenamiento de datos era un recurso valioso tanto en lo relativo al costo como a su disponibilidad, y el formato de tarjetas de 80 columnas influía sobre todas las teorías de diseño de registros. Los antiguos departamentos de proceso de datos, en estrecha cooperación con los escasos vendedores de productos de proceso de datos entonces existentes, desarrollaron múltiples técnicas para conseguir espacio adicional. Las fechas fueron una de las primeras cosas a las que se recurrió para ahorrar unos cuantos bytes.

La necesidad de ahorrar unos pocos bytes fue el origen del denominado Efecto 2000. En aquellos años, los programadores decidieron que el número 60 en un campo de año de dos dígitos resultaba adecuado para designar el año 1960. La automatización se centraba principalmente en funciones internas, como la contabilidad, y las matemáticas de las fechas tenían menos importancia en aquellos primeros años del sector informático, ya que eran pocos los que tenían que tomar en consideración los posibles problemas del año 2000. En la mayoría de las universidades enseñaban titulados que habían alcanzado su graduación en el año 00, e incluso algunos procedían de clases de los años 90 (años 1890), pero ninguno había considerado siquiera la posibilidad de automatizar algo tan esotérico como los registros de los alumnos. En el segundo tercio de este siglo nadie se preocupaba de cosas como el próximo milenio o el año 2000.

Se desarrollaron por otra parte técnicas ingeniosas para reducir la necesidad de almacenar fechas completas. Obviamente, nadie necesitaba el "19" como comienzo del año y, si se podía aplicar la lógica para determinar el día del mes (por ejemplo, "su pago vencerá el día 30 de este mes", incluso se truncaba el día en una fecha de vencimiento.

Además, para los pocos casos en los que se requería una matemática de fechas, los programadores reinventaron la fecha del calendario Juliano y la almacenaron, ahorrando así un valioso byte.

De vez en cuando, algún programador con amplia visión de futuro planteaba la cuestión del próximo cambio de siglo, pero los costes de almacenamiento de datos y la presión de los asuntos más urgentes prevalecían en la mayoría de los casos. Sólo resultaban afectadas las aplicaciones que manejaban valores con vencimiento a 40 años. El concepto del año de dos dígitos era tan corriente que la fecha de los sistemas se expresaba en forma de DDMMAA.

Año 2000; ¿a quién afecta el problema?

El problema del año 2000 es la consecuencia de dos factores. En primer lugar, una serie de funciones de proceso producirán resultados incorrectos a menos que las fechas del año se expresen en alguna forma que les permita reconocer el cambio de siglo. Por ejemplo, las rutinas de cálculo y lógica, como "calcular los días entre (fecha) y (fecha)"; "comparar (fecha) y (fecha)", o "clasificar en orden ascendente o descendente", fallarán cuando una fecha quede incluida en el siglo XXI y la otra en el siglo XX. En segundo lugar, la presentación de la fecha deberá ser estandarizada de tal forma que no haya confusión respecto a qué fecha es representada. En las aplicaciones antiguas ya existentes, las fechas se expresan en forma AAMMDD en aproximadamente un 10% de los casos, y como MMDDAA en un 85% o más de los casos (en la mayor parte de Europa, el formato de datos más habitual es DDMMAA).

El problema del año 2000 ha permanecido con nosotros desde aquellos primeros días, y no se ha hecho nada al respecto a escala mundial, a pesar de que los costes de almacenamiento se redujeron de manera drástica. ¿Por cuánto tiempo podrá aplazarse este problema? Tan pronto como las necesidades de la empresa u organización requieran registros que abarquen la ruptura entre siglos, la compañía deberá realizar el cambio. El problema no es nuevo, pero es ahora cuando está afectando a muchos más elementos de la actividad comercial. Los sistemas de contabilidad y los registros de activos fijos con amortización superior a cinco años también resultan afectados. Los contratos comerciales por más de cuatro años también sufren las consecuencias, y lo mismo los sistemas de planificación a largo plazo que cubren más de cinco años. Con unas pocas excepciones, deberá cumplirse con las medidas necesarias muchos meses antes de diciembre de 1999.

En consecuencia, quedan menos de 1000 días laborables desde el momento en que se lee esta edición y la fecha en que los sistemas de fechas deberán cumplir "con las normas del milenio".

¿Realidad o ficción?

Algunas personas se preguntan si el alcance del problema no habrá sido exagerado por los vendedores de productos y servicios orientados a la solución del Efecto 2000 y por los autores de artículos como éste. Algunas sugerencias de que las aplicaciones con gran "intensidad de fechas" puede requerir la revisión de hasta un 85% de su código podrían resultar excesivas. Incluso las estimaciones que sugieren que un 25% de toda el código existente está relacionado con fechas parecen demasiado elevadas. Según los datos que maneja la consultora IDC para una aplicación de medio millón de líneas de código, la cantidad total de definiciones y referencias de fecha alcanzó el seis por ciento y el porcentaje del total de definiciones y referencias de fechas en base a comparaciones de fechas o cálculos de fecha, el 0,5 por ciento. En consecuencia, el porcentaje del total de definiciones y referencias de fecha que fallarán en el año 2000 alcanzó un porcentaje del 0,12% Es decir; se producirán entre 550 y 575 fallos en la lógica relacionada con los datos en una aplicación. Si puede considerarse esto como típico -y no podemos asumir que lo es- una compañía con aproximadamente 25 millones de líneas de código podría sufrir entre 29.000 y 30.000 fallos en la lógica de fechas. Este impacto parece suficiente para que la compañía ponga en marcha un proyecto de corrección.

Los escépticos que no piensan que el problema del año 2000 afecta a su organización podrían tomar en consideración lo que se está realizando en las principales compañías de seguros de vida e incluso en la Administración de la Seguridad Social de Estados Unidos. Todas las empresas y organizaciones tienen en marcha un proyecto activo evaluando la cuantía del problema, y varias han iniciado proyectos para corregir codificación. Estas organizaciones, frente a la mayoría, han comprendido muy pronto la existencia de este problema.

Si no lo ha hecho ya, la Dirección de Sistemas de Información debe dirigirse ahora a la Dirección Corporativa y explicar que la compañía se enfrenta a la mayor tarea de mantenimiento de su historia, para la cual no habrá otro beneficio que el de poder continuar la actividad comercial. Además, la mayoría de las organizaciones no disponen de personal suficiente para resolver el problema, y los programadores con experiencia apropiada contratados son cada vez más escasos y más caros. Aunque sigue siendo posible recurrir al outsourcing y a la docena aproximadamente de compañías consultoras, todo el mundo se está apresurando a ponerse en la lista de espera. Estos proveedores se enfrentan al mismo problema de unos recursos y un control de calidad insuficientes, al extender y agotar cada vez más sus capacidades.

A tener en cuenta

Los factores que debe tener en cuenta la Dirección de Sistemas de Información a la hora de plantearse una solución para hacer frente al problema del Año 2000 son las siguientes:

- ¿Por qué han sido elegidas por el departamento de Sistemas de Información las opciones que se recomiendan?

- ¿Son las más económicas y apropiadas para esta empresa?

- ¿Qué alternativas fueron consideradas y rechazadas?

- ¿Qué recursos internos de la compañía se requieren para resolver el problema?

- ¿C