Estos últimos tiempos se han transformado en un estallido de opiniones y comentarios con respecto al efecto año 2000, también llamado Y2K (Y: year -año en inglés-, K: Mil), "Y200", o "virus del milenio".

El problema se origino en la década del `60, cuando las computadoras eran unas extrañas maquinas, que solo usaban los científicos y poderosas entidades bancarias. Los programadores forzaban el ingreso de datos en las tarjetas perforadas. El ancho disponible era de 80 espacios. Fueron las primeras codificaciones destinadas a ser interpretadas por una maquina.

Por entonces, las memorias de las computadoras eran muy cara y los programadores adoptaron la costumbre de representar los años solo con los dos últimos dígitos, y teniendo como preestablecido los dos primeros, es decir "19...", de este modo, cuando comienza el año 2000 estos sistemas informáticos o equipos electrónicos, se situarán en el año 1900, generando errores de distinta gravedad en el procesamiento de datos.

También los microchips, el cerebro de las maquinas, manejan fechas, y algunos de ellos también trabajan con solo 2 dígitos para el año. Muchos de estos chips controlan procesos industriales.

Problemas en sistemas embebidos.

Sistemas tan cotidianos como los teléfonos y ascensores, entre otros, son poseedores también de microchips vulnerables al problema del Y2k. Estos sistemas, son los pilares en los que se asienta la vida diaria y la dinámica corporativa, y su correcto funcionamiento es fundamental para el negocio, quizás más que las mismas computadoras.

Aproximadamente en los inicios de la década del noventa cuando comenzaban a surgir las inquietudes en relación al Y2K se pensaba que se trataba de un problema de software, desconociéndose en aquella época el vínculo con los sistemas embebidos.

Hasta el momento se han catalogado como sospechosos agitadores del año 2000 a casi 2300 ítems (incluyendo sistemas de control de planta, sistemas de distribución de control y sistemas de monitoreo de misión continua, sin olvidar los mundanos teléfonos y ascensores). Y teniendo en cuenta que estos últimos sistemas son la base del funcionamiento de los negocios, no pueden ser pasados por alto.

Emprender la búsqueda de dispositivos que contengan sistemas embebidos pueden resultar un tanto difícil. Para facilitar esta búsqueda a continuación detallamos una serie de pautas que le facilitarán la evaluación de las condiciones.

Para emprender la búsqueda, se deben seguir los siguientes pasos:

1.¿El sistema muestra o imprime hora y fecha? Esto indicaría que alguna clase de ecuación temporal está involucrada en el funcionamiento del aparato.

2. ¿El sistema debe presentar informes en forma regular? Si el dispositivo debe generar informes en los cuales se incluye fecha, entonces pueden surgir inconvenientes.

3. ¿El sistema funciona como centro de almacenamiento de registros históricos? Si las fechas son almacenadas, también pueden ser manipuladas y ordenadas.

4. ¿El sistema rotula productos en base a criterios temporales? Si un sistema rotula documentos, logos o productos, es probable que requiera una fecha y que no esté preparado para manejar los cuatro dígitos.

5. ¿El sistema involucra una secuencia temporal para su funcionamiento? Si un sistema activa o detiene una función en base a la fecha u hora, probablemente tenga problemas.

6. ¿El sistema debe realizar operaciones relacionadas con hora y fecha? Los sistemas que realizan sus funciones en base a hora o fecha, como por ejemplo el cierre de accesos o puertas durante fines de semana o feriados, trabajan en base a la fecha correcta.

7. ¿El sistema debe realizar cálculos relacionados con diferencias entre horas o fechas? Aquellos sistemas que determinen intervalos, promedios o calculen tiempos totales podrían estar en peligro con la llegada del año 2000.

8. ¿El sistema requiere el ingreso de hora o fecha al encenderse? Al suministrar energía un sistema, fecha-dependiente puede requerir el ingreso de este dato para continuar funcionando.

9. ¿El sistema envía información relacionada con horas o fechas a otros sistemas? Si un sistema recibe información temporal desde otros sistemas, puede llegar a tener problemas. Los sistemas que deben sincronizarse para funcionar a la par de otros son estrictamente dependientes de hora y fecha exactas.

10. ¿El sistema recibe información temporal desde otros sistemas? Si el sistema en cuestión no presenta inconvenientes, probablemente necesite manejarse con fecha correcta.

11. ¿El sistema posee algún comando que permita el ingreso de fechas? Si el dispositivo o sistema permite el ingreso de este tipo de datos, probablemente necesite manejarse con la fecha correcta.

12. ¿El sistema es capaz de asociar un día de la semana con su fecha? Por ejemplo, cuando el sistema es capaz de determinar si el 1º de junio de 1998 será lunes u otro día, entonces es posible que cuente con alguna función de tipo calendario, por ende es de esperarse que surjan problemas en el año 2000.

13. ¿El sistema activa sistemas de alarma en base a alguna clase de intervalo temporal? Si un sistema genera algún tipo de notificación en base a un período de tiempo dado, es probable que haya un contador de tiempo involucrado. Los contadores no presentan problemas horarios, pero si están asociados a un reloj de tiempo real pueden llegar a tenerlos. Es difícil determinar cuál es el dispositivo en uso, por lo tanto todos estos sistemas son sospechosos.

14. ¿El sistema exhibe o imprime información relacionada con secuencias temporales? Registros o listados de eventos ordenados por fecha indican dependencia de una función de fecha.

Si su respuesta a alguna de las preguntas es "sí", el dispositivo en cuestión debe ser considerado sospechoso.

Más allá de lo difícil que pueda resultar desentrañarlos, los problemas Y2K inherentes a los sistemas embebidos alcanzan un espectro más amplio –y de resolución potencialmente mucho más costosa- que los relacionados con los sistemas de cómputos.

Por último, podemos decir que la mayoría de los gerentes del proyecto Y2K pertenecientes al sector de tecnología informática de las corporaciones han realizado un mal desempeño en la identificación de infraestructura y otros dispositivos que pudieran contener sistemas embebidos susceptibles de error (según lo afirma un reporte producido por Harden de Century Technology Services). Este calificativo se debe a que la tarea de inventariar todos los dispositivos portadores de sistemas embebidos es ardua y éstos no se hallan acostumbrados a realizarla.

A continuación presentamos una lista de dispositivos potenciales víctimas de los problemas Y2K debido a sus sistemas embebidos:

Relojes despertador Sistemas de alarma

Cámaras Conmutadores telefónicos

Cerraduras automáticas Bóvedas y cajas fuertes

Máquinas de fax Calderas

Teléfonos celulares Sistemas de iluminación

Organizadores personales Sistemas telefónicos

Relojes Computadoras personales

Semáforos Fotocopiadoras

Videograbadoras Señales electrónicas

Ascensores Sistemas de radar

Sistemas de refrigeración Dispositivos biomédicos

Vehículos Dispositivos aeronáuticos

Si no se actualizan los sistemas, podrían surgir graves problemas. Es probable que no suceda todo simultáneamente, pero se esperan muchas pequeñas fallas.

En el hardware, el Real Time Clock (reloj de tiempo real) está presente en computadoras y aparatos electrónicos.

 

• El aparato puede calcular mal, apagarse o "volverse loco" si el chip no es reemplazado.

 

• Se lo llama "embebido": es parte del equipo.

 

• Los que no sean reemplazados producirán su error exactamente para el año nuevo.

Software (Programas de computación)

 

• Tienen acciones que trabajan con la fecha.

 

• La solución es corregir la fecha en las líneas de programación, o cambiar el programa.

 

• Sin corrección, el problema surge cuando se acciona esa parte del programa.

Diferentes problemas que ocasionará el Y2K en las ciudades.

 

• Viviendas: las alarmas dejarían de funcionar o se activarían descontroladamente. El control de iluminación y temperaturas dejaría de funcionar. Los ascensores programables se detendrían en planta baja y dejarían de funcionar.

 

• Computadoras: si no está preparada no anda y aparece un cartel que indica "real time failure".

 

• Servicios: electricidad y comunicaciones son los más expuestos por su nivel de automatización.

 

• Telefonía: las centrales automáticas fallarían y dejarían de funcionar.

 

• Semáforos: una falla en los controles de tiempo provocaría su salida de servicio.

 

• Salud: toda la tecnología de terapia intensiva depende de fechas. Sería imposible operar con aparatos sin actualizar.

 

• Electrocardiogramas: los lectores confundirán los campos y emitirían información errónea.

 

• Bancos: las cajas de seguridad podrían abrirse fuera de horario o no abrirse más. Los cajeros no registrarían las operaciones o lo harían mal.

 

• Facturación: la medición, el procesamiento y la emisión están sujetos a la fecha. La pérdida de datos ocasionaría enormes daños económicos.

Muy pocos artefactos del hogar pueden verse afectados por el problema del año 2000. Esto se debe a que ese problema solamente alcanza a algunos equipos que necesitan manejo de fechas para su funcionamiento. Por lo tanto, no hay que preocuparse por la inmensa mayoría de los productos del hogar. Como ejemplo podemos destacar el caso de los hornos a microondas que, a pesar de ciertas afirmaciones, no se verán afectados.

Los países desarrollados se preparan para la ¨bomba¨ informática del 2000 como si se tratara de una catástrofe natural.

En Estados Unidos, la Guardia Nacional realizó una prueba de comunicación entre los 52 estados sin usar electricidad ni teléfonos, algo que no se había probado desde la Segunda Guerra Mundial.

Los 480.000 hombres preparados recibirán el año en "estado de alerta máxima", por el temor a los problemas que pueden ocasionarse por el desperfecto de aparatos eléctricos o computadoras. Sin embargo, Bill Clinton anunció que "la nación está tecnológicamente preparada para enfrentar el 2000".

En Inglaterra, el gobierno recomendó almacenar víveres por una semana.

Los mayores temores en los países desarrollados son el caos atómico y financiero, y son las áreas con prioridad en la preparación para hacer frente al problema Y2K.

Las Naciones Unidas, en una circular repartida a sus empleados en distintos lugares del mundo, les recomendó "no asumir que las tarjetas de crédito, los cajeros automáticos, operarán normalmente". Además les sugirió tener alimentos, agua y los medicamentos de uso regular para una semana como mínimo, así como también frazadas extra y medios de calefacción alternativos si están en el hemisferio norte, donde será invierno linternas, pilas, nafta para un generador eléctrico y el tanque lleno del auto desde mediados de diciembre.

 

• Canadá es uno de los países que se considera mejor preparado para afrontar el problema. El ejército lleva adelante el plan ABACUS, con un presupuesto de 386 millones de dólares, en el que las tropas ya ensayaron evacuaciones de pueblos y acciones ante posibles cortes de luz generalizados.

 

• Italia es considerado uno de los países desarrollados que menos se ha ocupado del problema.

 

• El Vaticano está preocupado por el problema. Ya formó el Comité de Seguridad, integrado por seis obispos y cardenales, que coordinará a los 100 guardias suizos y 120 guardias especiales. Se teme que en la multitudinaria peregrinación que se realizará en Roma y el eventual caos, peligre la vida del Papa Juan Pablo II.

 

• En Francia, la CIGREF, un Club de Usuarios de Informática que nuclea a las 100 empresas más importantes del país, es responsable del proyecto del año 2000. Es un proyecto de gerencia, no sólo destinado a la división informática. La propuesta de dicha utilidad se plasma en un CD-ROM, el Marjori 2000, que resulta de la experiencia del grupo de usuarios de estas 100 grandes empresas. La dificultad en Francia es la descentralización. El Estado, las regiones, los departamentos y las comunas se delegan el problema Y2K entre sí. Es un problema transversal para toda la economía y la sociedad.

 

• En España existe un proyecto de ley de paso del año 2000 para la administración española, y hay una serie de normas.

Global 2000 es una organización internacional sin fines de lucro que ha realizado un ranking mundial de situación: calificó con rojo las áreas críticas, con amarillo las que tienen atrasos, con verde las que están al día y con negro las que no hay información.

 

• China y Rusia calificaron en rojo para todas sus áreas. A estas dos potencias le sigue Malasia, entre los peores países preparados del planeta.

 

• Argentina en el ranking fue calificada en amarillo para las áreas de agua, energía y sistema financiero, y en negro para transporte.

 

• África prevé problemas. Sólo 4 estados en el continente habían tomado medidas concretas para enfrentar el problema.

 

• En Latinoamérica la situación es irregular. Brasil y Chile han planteado el tema con seriedad. México, Venezuela, Ecuador y Colombia están más atrasados.

El 16 de Diciembre de 1998 se suscribió un Memorandum de Entendimiento entre el Gobierno de la República Argentina y el Gobierno de la República de Chile, de cooperación para afrontar el Problema Informático del Año 2000. Se creó de una Comisión Ad-Hoc integrada por representantes de el Ministerio de Relaciones Exteriores y Culto y de la Secretaría de la Función Pública de la Jefatura de Gabinete de Ministros, por la República Argentina; y representantes del Ministerio de Relaciones Exteriores, de la Dirección de Asuntos de Gestión de la Presidencia de la República y del Ministerio de Planificación, por la República de Chile.

Conforme a la convocatoria hecha por los Presidentes de los Estados Miembros del Mercosur, Chile y Bolivia en comunicación conjunta con motivo de la XIV Reunión del Consejo de Mercado Común los días 23 y 24 de Julio de 1998, en la ciudad de Ushuaia, se creó el Grupo de Trabajo Ad-Hoc sobre el problema informático del año 2000 (GTAH2000).

En la Ciudad de Buenos Aires, durante los días 27 y 28 de Abril de 1999, se celebró el Foro Iberoamericano sobre "La Responsabilidad del Estado frente a la Problemática del Año 2000", convocado por el Centro Latinoamericano de Administración para el Desarrollo (CLAD), la Conferencia de Autoridades Iberoamericanas de Informática (CAIBI), la Secretaría de la Función Pública (SFP) y el Instituto Nacional de la Administración Pública (INAP), y con el apoyo de la Agencia Española de Cooperación Internacional (AECI) conjuntamente con la Fundación Instituto Iberoamericano de Administración Pública (FIIAP).

El Foro de Coordinadores Y2K de América del Sur es una iniciativa que surgió en la Conferencia sobre el Problema Informático del Año 2000, realizada el 11 de Diciembre de 1998 en Naciones Unidas, ciudad de New York. En esa ocasión, los Representantes de América del Sur acordaron crear el Foro como mecanismo de Cooperación, Coordinación y Comunicación entre los equipos responsables de los Proyectos Nacionales Y2K.

El GTAH2000 tiene como objetivo final proporcionar la información necesaria que permita preparar adecuada y oportunamente el pasaje al año 2000 para los Estados participantes.

La primera Reunión del GTAH 2000 se realizó durante los días 10 y 11 de Septiembre de 1998, en la ciudad de Brasilia, con la participación de delegaciones de Argentina, Brasil, Paraguay, Uruguay, Chile y Bolivia. Se definieron como sectores prioritarios de trabajo:

•Energía •Telecomunicaciones •Transportes (aéreo, marítimo, terrestre) •Financiero •Fronteras (migraciones, aduanas, y seguridad)

Se acordó realizar las acciones necesarias para la creación de condiciones que faciliten el intercambio de información, tanto de carácter general cuanto referidas a los sectores específicos.

Para cada uno de los sectores prioritarios se constituyeron Subgrupos de Trabajo, con el propósito de implementar las siguientes acciones:

•Identificación de las relaciones con los demás países de la región, de acuerdo a su condición de receptor o proveedor de productos o servicios. •Inventario de la infraestructura transfronteriza existente •Identificación de los agentes involucrados (públicos o privados) · Priorización de las áreas comunes

•Estado de situación de áreas prioritarias comunes •Acciones conjuntas necesarias •Coordinación de medidas y Planes de Contingencia

Con el fin de generar condiciones que permitan llevar a cabo las acciones, se designaron facilitadores para cada una de las áreas:

•Energía ------------------- República Federativa de Brasil •Financiero ---------------- República de Bolivia •Fronteras ----------------- República Oriental de Uruguay •Telecomunicaciones ------ República Argentina •Transporte ---------------- República de Chile

Se definieron como áreas de interés bilateral las siguientes:

•Energía •Telecomunicaciones •Transportes (aéreo, marítimo, terrestre) •Financiero •Fronteras (migraciones, aduanas, y seguridad)

Los objetivos de la Comisión Ad-Hoc se centran en:

•La determinación de las actividades que pueden ser afectadas pro el denominado "Problema del Año 2000" •La determinación de las actividades pertinentes para asegurar que los problemas previstos en las áreas de trabajo sean corregidos, o sean objeto de planes de contingencia. •La obtención e intercambio de información sobre los planes de adecuación •Sugerir acciones correctivas ante eventuales desvíos en la ejecución de los planes

Se estableció un Reglamento de Funcionamiento, donde se crearon los siguientes Subgrupos de Trabajo:

•Energía •Telecomunicaciones •Transportes (aéreo, marítimo, terrestre) •Financiero •Fronteras

Se estableció el siguiente Plan de Acción para cada uno de los Subgrupos:

•Los Subgrupos de Trabajo establecerán un estado de situación por sectores prioritarios •Identificación de situaciones críticas •Identificación de posibles y/o necesarias acciones conjuntas •Estudio de las bases de un Plan de Contingencia Bilateral •Plan de trabajo conjunto

•Ejecución de las acciones conjuntas acordadas •Implementación de medidas y planes de contingencia acordados

El Foro de Coordinadores Y2K de América del Sur es una iniciativa que surgió en la Conferencia sobre el Problema Informático del Año 2000, realizada el 11 de Diciembre de 1998 en Naciones Unidas, ciudad de New York. En esa ocasión, los Representantes de América del Sur acordaron crear el Foro como mecanismo de Cooperación, Coordinación y Comunicación entre los equipos responsables de los Proyectos Nacionales Y2K.

Se acordó como punto focal del Foro Regional el sector de Energía y en la formulación de un Plan de Contingencia Regional del Sector Energía.

Se creó un Subgrupo de Trabajo de Energía de América del Sur, coordinado por el Coordinador Nacional Y2K de Brasil y el representante del sector de Energía de la República Argentina.

Se finalizó el inventario detallado de la infraestructura de energía de cada país que incluya las interconexiones con otros países.

Se convocó a una reunión de los Coordinadores de los Sistemas Eléctricos a ser realizada en la Ciudad de Río de Janeiro, para el intercambio de experiencias en relación al efecto del año 2000. Y se acordó propiciar la creación de un grupo permanente de trabajo de los coordinadores de los Sistemas Eléctricos Nacionales.

Se estableció una red de comunicaciones entre todos los Coordinadores Nacionales a través de teleconferencias.

Se realizaron, con la presencia de expertos de distintos organismos internacionales y privados, los siguientes talleres:

•Emergencias Y2K que constó de tres módulos: Información, Comunicación y Estructura. •Planificación de Contingencia: Funciones Críticas que deben ser cubiertas por el Plan Nacional de Contingencias, Identificación de los riesgos asociados a cada Función Nacional Crítica, Metodología de planeación de contingencias, Aplicación de Planes de Contingencia a sectores críticos: Salud, Telecomunicaciones y Transporte. •Planes de Contingencia en el Sector Financiero, presentado por experto del Global 2000 •Transporte Aéreo: Metodología y grado de avance, representante del IATA

Se elaboró un documento "Guía de Referencia para la elaboración de los planes de contingencia del Sector Eléctrico", con la participación de expertos del sector de Argentina, Colombia y Venezuela. Se contó con la participación de un experto del Edison Electric Institute, que realizó una presentación sobre las acciones llevadas adelante por el NERC de Estados Unidos y los resultados de los últimos simulacros y ejercicios.

Estudiar la posibilidad de crear un "Grupo Sudamericano de Recuperación de Fallas", y el análisis de los posibles mecanismos de participación, cooperación y financiamiento. Establecimiento, de acuerdo a las posibilidades y diseño de cada país de un Centro de Manejo de Emergencias tipo Y2K y uno de carácter regional que será virtual.

Definir como sectores prioritarios a monitorear los siguientes: Energía, Telecomunicaciones, Transportes, Salud, Finanzas.

Establecer una "ficha" modelo de seguimiento de falla para consignar la información relevante de cada sector y cada situación, teniendo en cuenta la descripción de la falla, equipos involucrados, eventual solución del problema.

Diseñar una base de datos que será alimentada por cada país, orientada a identificar los stocks de suministros críticos que se podrían ver interrumpidos por fallas del tipo Y2K, en la página Web del Foro, en particular los suministros médicos.

Considerar el establecimiento de Mesas de Cooperación virtual a nivel de cada sector prioritario.

Fortalecer tecnológicamente la teleconferencia de Coordinadores Nacionales, con el objeto de que este mecanismo sea el instrumento para monitoreo de la transición al 2000 de la región y de esta con el resto del mundo.

Establecer un inventario de sistemas de telecomunicaciones alternativos de los Coordinadores Nacionales, y un Directorio con los responsables de cada sector prioritario por país.

Reuniones Realizadas:

•I Reunión General del Foro, 4 y 5 de marzo de 1999, Lima •I Reunión del Subgrupo Energía, 29 de Abril, Buenos Aires •II Reunión General del Foro, 19 al 21 de Mayo de 1999, Washington D.C. •II Reunión del Subgrupo Energía, 26 y 27 de Julio, Buenos Aires (Criterios Mínimos para la elaboración de un Plan de Contingencia en el Sector Eléctrico) •III Reunión General del Foro, 5 y 6 de Agosto de 1999, Bogotá, Colombia

Próximas Reuniones •IV Reunión General del Foro, 3 al 5 de Noviembre de 1999, Santiago

La Argentina está preparada de manera despareja para afrontar la crisis informática del 2000. El error tecnológico de fechas provocará, si no se corrige a tiempo, desde problemas con el pago a jubilados hasta fallas en el sistema eléctrico, la distribución de alimentos y la venta de pasajes.

El sector argentino mejor preparado es el bancario y financiero. También avanzaron empresas que prestan servicios públicos. Las peores preparadas son las pequeñas y medianas empresas. Y, a mitad de camino, están el sistema de salud y administración pública.

Se calcula que la solución del problema costará a la Argentina alrededor de 1.500 millones de dólares. El país sufrirá un impacto económico de 4.800 millones de pesos, que provocará una caída en el bienestar de la gente del 0,35 % del Producto Bruto Interno nacional, algo así como 1.050 millones de pesos. Estas cifras surgen de un estudio realizado por el Instituto de Economía de la Universidad Argentina de la Empresa (UADE) y encargado por el gobierno nacional para medir el impacto que el cambio de siglo y sus consecuencias en el sistema informático mundial van a producir en la actividad económica del país. Aunque estos datos son variables a medida que se acerca el 31 de diciembre de 1999.

El 16 de enero de 1998, el Banco Central se adelantó al resto de las empresas y emitió una circular en la que especificaba a todas las entidades financieras las normas que deben seguir frente a la crisis.

Se han realizado pruebas para controlar el ritmo de actualización de los bancos. Pero no se puede asegurar que el sistema funcione ciento por ciento en los primeros días del 2000. Los clientes de los bancos podrían encontrarse con que los cajeros automáticos no reconocen sus tarjetas o cometen errores en los saldos.

Si llegaran a darse estas situaciones, es probable que los bancos cancelen momentáneamente la información al público.

En la administración pública, el Poder Ejecutivo Nacional creó la "Unidad Ejecutora 2000", que funciona en la órbita de la Secretaría de Función Pública. Debe buscar soluciones y brindar asistencia a organismos públicos.

Las prioridades son resolver las áreas financiera, previsional, el sistema de recaudación y el de liquidación de sueldos en la administración del Estado. "Cuando llegue el 2000, la recaudación y los pagos de pensiones y jubilaciones funcionarán normalmente", opinión de Claudia Bello, secretaria de la Función Pública.

El informe del Gardner Group de marzo de 1999 ubica a la Argentina entre los países menos preparados. Calcula que el 50% de las empresas y organismos de cada sector registrará al menos una falla importante el día "D".

Ni Edesur ni Edenor pudieron garantizar que estarían ciento por ciento actualizadas el 1º de enero del 2000.

Pequeñas y medianas empresas son las menos preparadas. Actualizar sus sistemas puede resultarles caro. Algunas lo hacen presionadas por empresas más grandes a las que les venden sus productos o servicios.

Según estadísticas del INDEC, hay cerca de 1.800.000 PyMES. De esta cifra, unas 200.000 están muy expuestas a la crisis, lo que las obligaría a detener su funcionamiento todo el tiempo que demore la actualización.

Las industrias alimentaria y farmacéutica pueden tener problemas con las fechas de vencimiento de sus productos.

Como sólo un 3 % de los médicos argentinos maneja una computadora en su consultorio, este sector no se verá tan afectado. Pero sí el de los equipamientos médicos que funcionan con sistemas sometidos a fechas. Por ejemplo, radioterapia, dosificadores automáticos de medicamentos, marcapasos externos, tomógrafos e incubadoras.

En el gobierno admiten, que los entes recaudadores (la DGI y la Aduana), así como las áreas de Salud, de Transporte y de Energía están entre los más atrasados en las tareas de prevención.

El test final para saber si el país está preparado para recibir el Año 2000 en sus sistemas informáticos se hará con dos simulacros: uno en el Hospital Posadas y otro en el aeropuerto Internacional de Ezeiza. Allí se sabrá si las medidas de prevención adoptadas son las correctas.

La FUERZA AEREA ARGENTINA tiene a su cargo la adecuación de los Servicios de Tránsito Aéreo (ATS)

Servicios de Tránsito Aéreo (ATS): Se ha obtenido la certificación de compatibilidad de la mayor parte de los servicios ATS

El Organismo Regulador del Sistema Nacional de Aeropuertos (ORSNA), la Subsecretaría de Transporte Aerocomercial, Fluvial y Marítimo, la Fuerza Aérea Argentina y el concesionario de los aeropuertos del Sistema Nacional de Aeropuertos han confirmado el Comité de Crisis 2000, que ha certificado todos los aeropuertos internacionales de la Argentina. Se verifico su continuidad operativa inspeccionando los sistemas de generación alternativa de energía de torre de vuelo, comunicaciones, balizamiento y radioayuda.

La Prefectura Naval Argentina, a través de su Comité de Seguridad Marítimo, ha adoptado medidas preventivas en referencia a la seguridad en la navegación, en función de las recomendaciones emitidas por la Organización Marítima Internacional (OMI).

La Subsecretaría de Puertos y Vías Navegables, está realizando el seguimiento de los planes de acción de las terminales portuarias. Además supervisa las acciones llevadas adelante por la concesionaria del servicio de Dragado y Balizamiento (desde Santa Fe al océano).

El transporte automotor y ferroviario en la jurisdicción Nacional, está bajo la órbita de la Comisión Nacional Reguladora del Transporte (CNRT).

Según el análisis de los planes de acción de transportistas y concesionarios de líneas realizado por la CNRT: No se prevén problemas que pudieran paralizar el servicio

Este sector se encuentra bajo el control de la Secretaría de Energía.

Organismos Reguladores:

•Ente Nacional Regulador de la Eléctrica (ENRE) •Ente Nacional Regulador del Gas (ENARGAS) •Autoridad Regulatoria Nuclear (ARN) •CAMMESA : Compañía Administradora del Mercado Mayorista Eléctrico S. A.

La Autoridad Regulatoria Nuclear (ARN), que fiscaliza los aspectos de seguridad específica en las centrales nucleares, lleva adelante el control de los planes de adecuación en las empresas por ella reguladas, habiendo incluido este aspecto en sus revisiones periódicas. Las 2 centrales nucleoeléctricas que operan en la Argentina, a principios de Abril, estaban avanzadas en aproximadamente el 70% de sus planes de adecuación.

Este sector está regulado por la Comisión Nacional de Comunicaciones (CNC), realiza el control de las empresas prestatarias del servicio de comunicaciones

El Banco Central de la República Argentina (BCRA), se ocupa de regir las entidades bancarias y financieras del país. Lidera, fija las pautas y realiza un exhaustivo control del proceso de adecuación de las instituciones del sector.

•Ministerio de ECONOMIA, OBRAS Y SERVICIOS PUBLICOS •MERCADO ABIERTO ELECTRONICO S.A. (MAE)

•SUPERINTENDENCIA DE AFJP

•SISTEMA BURSATIL ARGENTINO: Bolsa de •Comercio, Caja de Valores y Mercado de Valores

•COMISION NACIONAL DE VALORES (CNV)

El Ministerio de Salud y Acción Social coordina las acciones en este sector.

•Creó la Comisión Año 2000 (Sept. 1998). •Se definió un Plan de Acción Nacional. •Reunión del Consejo Federal de Salud para lograr alcance en todo el país. •Se realizó un proceso de concientización a distintos niveles, cámaras, federaciones, y otras entidades de salud. •Resolución 145/99: Prohibe el uso de equipamiento no compatibles a partir del 1ro. de setiembre de 1999. •Resolución 146/99: Todas las compras de nuevo equipamiento deben ser certificadas como compatibles.

ANMAT Administración Nacional de Medicamentos, Alimentos y Tecnología Médica.

El Ministerio de Trabajo y Seguridad Social dispone de la siguiente información:

•De la Administración Nacional de la Seguridad Social (ANSES) que se ocupa de administrar los fondos correspondientes a los regímenes nacionales de Jubilaciones y Pensiones, de Subsidios, de asignaciones familiares y del Seguro de Desempleo. •De la Superintendencia de Administradoras de Fondos de Jubilaciones y Pensiones (S.A.F.J.P) que se ocupa de ejercer el estricto control y supervisación del cumplimiento de la Ley 24.241 y de las normas reglamentarias que se dicten. También procura prevenir sus eventuales incumplimientos. •De la Superintendencia de Riesgos del Trabajo (SRT) que se ocupa de controlar el funcionamiento integral del sistema: regulando y fiscalizando a las aseguradoras, controlando el cumplimiento de la normativa relativa a la higiene y seguridad en el trabajo por parte de los empleadores, auditando el otorgamiento de las prestaciones previstas, promoviendo las acciones de prevención, etc.

ADMINISTRACION FEDERAL DE INGRESOS PUBLICOS:

Preguntas más frecuentes realizadas a la entidad.

Desde el inicio de la computación electrónica, los analistas y programadores informáticos diseñaron los sistemas tratando de reducir en todo lo posible la cantidad de espacio requerido para guardar los datos, debido a que el almacenamiento en las computadoras era muy caro.

Esto ocurrió en todo el mundo, no se trata de una  situación que afecte a un país u organismo específico.

Una forma de ahorrar era representar el dato año sólo con los últimos 2 dígitos, asumiendo que los 2 primeros eran 19, tal como cualquier persona interpretaría 19/06/49 como "19 de Junio de 1949".

La interpretación implícita humana seguirá vigente aún después del 2000, porque se asociará al contexto. Si la fecha fuera 19/06/00 y se está hablando de la fecha de nacimiento de una abuela o bisabuela, se interpretará 19/06/1900. Si se habla de un bebé se interpretará 19/06/2000. El problema es que las computadoras no saben de contextos; para ellas 49 o 00 son números, y pueden generar resultados incorrectos.

Si se trata de calcular la edad a partir de la fecha de nacimiento, para una persona que nació en 1930, el cálculo efectuado este año sería: 99 - 30 = 69 (edad correcta). Si el cálculo se efectúa el año próximo, el cálculo sería 00 - 30 = -30 (valor incorrecto).

La mayoría de las organizaciones, entre ellas ANSES, adoptaron hace algún tiempo el estándar de definir los años en 4 dígitos; pero esta definición tuvo efectos para los nuevos sistemas. Los desarrollos informáticos anteriores poseen el año en 2 dígitos, otros en 3 dígitos.

Esta realidad impuso la tarea impostergable de revisión de todos los programas y archivos informáticos, en las organizaciones que utilizan sistemas informáticos en el mundo.

En este marco, ANSES también debe prepararse para el año 2000 adecuando sus equipos y sistemas informáticos de modo que continúen las prestaciones y servicios que brinda a la comunidad.

ANSES ha asignado máxima prioridad a la resolución del problema, con el objetivo de evitar inconvenientes a sus beneficiarios y consecuencias no deseadas a la comunidad. Para ello se destinó el presupuesto correspondiente y se creó un proyecto específico, "ANS2000", conformado por profesionales calificados que trabajan con dedicación exclusiva en este tema.

La conducción de ANSES, consciente de la envergadura del problema, tomó las siguientes decisiones estratégicas:

-        Acordar la asistencia técnica de la Secretaría de la Función Pública en el proyecto, a través de su Unidad Ejecutora 2000.

-        Recurrir al concurso de servicio técnico privado que aporte valor agregado a los recursos humanos especializados de ANSES.

-        Instrumentar acciones tendientes a retener a los técnicos informáticos en un mercado laboral con alta demanda.

-        Refrendar y agilizar las acciones en curso para la renovación del equipamiento.

Para el desarrollo del Proyecto "ANS2000" se adoptó metodología recomendada internacionalmente por organizaciones dedicadas específicamente a la problemática del cambio de milenio. Las etapas que constituyen el proyecto son:

-        Concientización: comprende las actividades de divulgación del problema, organización del proyecto y de los equipos de trabajo y la planificación general del proyecto.

-        Evaluación y Planeamiento: comprende las actividades de inventario de sistemas informáticos y equipos, definición de cursos de acción, asignación de recursos humanos y económicos, y precisión del plan de acción.

-        Adecuación de sistemas y equipos: comprende la reparación o reemplazo de los componentes afectados, las solicitudes de certificación externas y la documentación de lo realizado.

-        Pruebas y validación: comprende las pruebas de los componentes para  verificar que funcionen correctamente con fechas de y entre los siglos XX y XXI, en sus diferentes niveles de agregación: unitario, sistema, organismo, inter-organizaciones.

-        Implementación: comprende la implementación de los componentes preparados para el Año 2000 en el ambiente de operación cotidiano de ANSES, la divulgación de la situación y el resguardo de la documentación.

Una de las recomendaciones internacionales estándares para la preparación de sistemas ante el cambio de milenio es la elaboración de planes de contingencia. Los planes de contingencia son medidas alternativas para superar posibles fallas en los sistemas ya que mundialmente se tiene plena conciencia de que, aún cuando se hayan certificado los sistemas informáticos para el año 2000, la solución no es completa si cada organización y/o empresa no cuenta con alternativas apropiadas.

En el marco del proyecto "ANS2000", se encuentran involucradas en la elaboración de dichos planes todas las gerencias de ANSES para determinar los riesgos, elaborar las alternativas de contingencia y capacitar al personal que debe llevarlas a cabo.

Dentro de la estrategia global de ANSES en su Proyecto "ANS2000", merece destacarse lo relativo a las instancias de control.

Es conocido que los proyectos del Año 2000 en organizaciones de envergadura como ANSES representan un importante desafío de gestión y de resultados técnicos, aumentado por la gran cantidad de componentes involucrados.

Adicionalmente al compromiso de ANSES con su Proyecto "ANS2000", el plan y las actividades referidas a este tema están sujetas a permanente supervisión de los organismos de control del Estado: Secretaría de la Función Pública, Auditoría General de la Nación y Sindicatura General de la Nación.

Además se ha contratado un servicio privado independiente de "Seguimiento, Control y Auditoría" para asegurar que el proyecto de adecuación de los sistemas centrales logre su objetivo en tiempo y forma.

Correo Electrónico: [email protected]

Administración Nacional de la Seguridad Social

Buscan calmar a los ahorristas · Y reemplazarán con empleados a los cajeros automáticos con problemas

Por LUCAS GUAGNINI. De la Redacción de Clarín.

El riesgo de una eventual corrida bancaria, la recategorización de la cartera de deudores según se hayan preparado o no para el efecto 2000 y un control en las computadoras centrales de los bancos son los tres temas que desvelan al sector financiero en su puesta a punto para recibir el cambio de siglo sin sorpresas. Y asegura que lo logrará.

El sistema financiero argentino fue el primer sector que, junto con las empresas multinacionales, comenzó a ocuparse del efecto 2000. El Banco Central emitió su circular número uno sobre el tema a mediados de 1997. Para entonces varios bancos que tienen su casa matriz en el exterior ya trabajaban sobre el problema.

No es para menos, prácticamente todas sus operaciones están informatizadas e incluyen la variable fecha. Como las computadoras producen errores o se apagan al leer el paso de 1999 al 2000, con el cambio de siglo el riesgo de colapso era altísimo.

Para evitar una corrida de los ahorristas provocada por el miedo a un colapso de algunos bancos, el Central fijó férreas normas: los bancos tienen prohibido hablar con los medios de su avance informático. Tampoco se les permite hacer publicidad diciendo que ya están listos tecnológicamente para recibir el 2000. Habría pánico respecto a los que no publicitaran.

Rubén Escobar, el encargado de controlar el avance de los bancos desde la auditoría del Banco Central, explicó en una conferencia brindada en el Freedom Forum: "Por ahora el Banco Central no tiene una política de comunicación al respecto".

Además del hermetismo, según revelaron a Clarín fuentes del Banco Central, se estudian varias medidas. Decretar el viernes 31 de diciembre de 1999 y el lunes 2 de enero del 2000 feriado bancario y así evitar que los eventuales problemas en los sistemas afecten al público y lo asusten. Además, planean poner cajeros humanos el fin de semana de Año Nuevo, tanto sábado como domingo, para reemplazar a los cajeros automáticos que puedan fallar.

Y estudian bajar el encaje, para que exista mayor cantidad de dinero circulante y, si el público decide sacar algunos ahorros extras, no escaseen billetes en el sistema.

Estados Unidos, por ejemplo, emitió 70 millones de dólares que se sumaron a los 150 millones que la Reserva Federal tiene listos para poner en circulación y evitar la falta de billetes. Pero según explicó Escobar, "eso es porque allí casi no se utiliza el efectivo y prevén más demanda de billetes por los problemas que puedan ocasionar la salida de funcionamiento de algunas tarjetas".

Además, el plan de emergencias del Banco Central está evaluando que, si un banco no puede abrir alguna de sus sucursales, otros bancos puedan efectuar sus operaciones.

El problema de la corrida de inversionistas extranjeros es más difícil, ya que pueden concluir que la región está mal preparada para afrontar el efecto 2000 y bajar sus participaciones sin hacer mucha distinción por país, admiten los operadores. Este tipo de comportamiento ya se dio durante la crisis mexicana y la brasileña.

Otro tema que preocupa a los banqueros por estos días, la "evaluación de riesgo 2000" de sus deudores, tampoco es menor.

Enrique Rivas, responsable del Proyecto año 2000 en el Banco de Galicia, contó: "Mandamos un cuestionario al 15 por ciento de la cartera de deudores preguntando cuánto invirtieron, qué hicieron en los distintos pasos del proyecto y si tienen un plan de contingencia para atacar los problemas que pueda causar el cambio de fecha en los equipos de sus empresas".

Roberto Bartoletti, jefe del departamento de normas y operatoria bancaria de la Asociación Bancos de la Argentina, explica que de las previsiones que se tomen en este aspecto "depende la supervivencia del negocio. Al principio había muy bajo nivel de respuesta de los deudores. Las empresas decían que era un invento de las consultoras y de las empresas de informática para vender sistemas. Ahora entendieron la gravedad del asunto". Y explica que la "necesidad de evaluar el riesgo del crédito es enorme, porque de muy poco serviría si los bancos están al día pero sus deudores no cumplen".

Luego de hacer varias pruebas, el sector está casi listo técnicamente para soportar el cambio de fecha, sin embargo queda un aspecto informático por resolver: la computadora central de una red, denominada mainframe, tiene en su interior un chip que controla el tiempo, llamado "reloj biológico" o "reloj de tiempo real". La mayoría de los bancos aún no controló que este reloj sea capaz de pasar el año nuevo sin ocasionar problemas en el centro neurálgico de sus equipos: el mainframe memoriza las transacciones y los estados de cuenta de todos los clientes.

Bartoletti, de ABA, explica: "IBM (la marca de la mayoría de los mainframes) no recomienda adelantar la fecha del reloj biológico. Creo que muchos bancos no van a hacerlo, ya que no todos tienen un segundo equipo central para archivar sus datos mientras hacen las pruebas".

-¿Cuál es el riesgo? -El problema es que no saben si van a poder volver a 1999 si adelantan la fecha. Se trata de un chip muy delicado.

Luis La Rosa, director del Proyecto año 2000 para Latinoamérica sur de IBM, afirma: "El Banco Central les exigía a los bancos que adelantaran la fecha de sus mainframes, pero cuando nos consultaron nuestros laboratorios no lo recomendaron. De todas maneras dimos un listado de las precauciones que tiene que tomar el que lo haga. Nosotros ya hicimos la prueba y comprobamos que los equipos pasan bien el cambio de siglo". En el Central se quejan porque IBM no les envió una carta certificando que no tendrán problemas. La Rosa replica: "Todo el mundo quiere transferir la responsabilidad a otro".

© Copyright 1996-99 Clarín Digital.

¿Cuál es la mejor forma de comenzar cuando se arranca demasiado tarde? Dar un paso a la vez. Los siguientes son diez consejos para prevenir el "pánico del año cero".

1. No se trata de un ultimátum paterno.

El plazo que vence el 31 de diciembre de 1999 es la primera fecha en la historia de la tecnología informática que no puede ser diferida, negociada, debatida o simplemente ignorada. "Los sistemas de misión crítica que se vean afectados por el cambio de fecha, no pueden ser terminados o corregidos tardíamente", observa Peter de Jager, un experto del tema del Año 2000.

Es necesario concentrarse en esa fecha final, trabajar hacia atrás y fijar prioridades, según los recursos y limitaciones, así será el resultado que obtenga.

2. No reinventar la rueda.

Como no se cuenta con los tiempos ni los recursos necesarios para comenzar de cero, se debe aprender de los errores de otros.

3. No quedarse parado, hacer algo.

Es necesario poner el proyecto en marcha rápidamente. En principio, se debe tener una idea general del alcance del proyecto. Luego poner en marcha un proceso consistente, repetible y capaz de manejar tanto volumen como sea posible. Cuanto menos digitaciones, mejor. Esa es la meta.

Si bien ninguna herramienta será capaz de detectar y corregir el 100 % de los campos de fechas, la automatización resulta esencial para asegurar resultados consistentes .

4. El momento de las prioridades.

El objetivo de las pruebas o ensayos no es preservar a los sistemas en forma individual, sino salvar a la empresa cuyo funcionamiento se basa en ellos. Se debe seguir un sistema de prioridades que ha sido diseñado para maximizar la cantidad de sobrevivientes. No será fácil, pero es la única forma en la que se podrá salir de la crisis con los suficientes sistemas intactos como para recibir pedidos, despachar un producto, imprimir una factura y pagar al personal.

Esta es una lista de aplicaciones y su clasificación en cinco categorías, cuya sigla en inglés es ANGST.

A: absolutamente necesarias. Son los sistemas en los que se juega el negocio, y sin los cuales la compañía quedaría fuera del negocio.

N: es necesario tenerlos. La pérdida de estas aplicaciones representaría un problema para muchos usuarios. Muchas funciones importantes del negocio se verían desestabilizadas, pero el negocio continuaría funcionando.

G: bueno tenerlas. Son los sistemas que para un pequeño grupo de usuarios son críticos, pero que en realidad agregan muy poco valor a la supervivencia de la empresa.

S: poco tiempo. Estas son aplicaciones de consulta y generación de reportes desarrolladas para usuarios individuales. Se las procesa por acostumbramiento.

T: para tirar. El inventario de las aplicaciones está repleto de sistemas que no han sido utilizados en un año o más.

5. Si no se ha roto, no arreglarlo.

Las aplicaciones que se ubican dentro de este grupo tienen una clasificación adicional: aptas o no aptas para el año 2000. Es posible, que algunas de las aplicaciones de misión crítica ya estén completamente adecuadas para el año 2000. De ser así, no meterse con ellas.

 

6. Si está roto, es mejor reemplazar.

Algunas veces es razonable desprenderse de las aplicaciones heredadas y reemplazarlas con una solución certificada como apta para el año 2000. Las compañías que eligieron el camino del arreglo, gastarán dinero para no obtener ningún valor agregado. La solución es la siguiente: No arreglar los sistemas, reemplazarlos. Así podrá resolver el problema del milenio al mismo tiempo que introducirá mejores prácticas dentro de su negocio.

7. La prueba es la equivalencia funcional.

El fin último de todo proyecto de conversión para el año 2000 es que "el antes" y "el después" de los sistemas sea funcionalmente equivalente.

8. Hacer reingeniería de su propio tiempo.

Si superpone el proyecto del Año 2000 con la realización de otras mejoras, lo único que logrará es crear tremendas dificultades en la administración del proyecto y, hacer que el testeo resulte más difícil.

9. Tendrá que hacer windowing.

Existen dos principales metodologías de conversión entre las cuales elegir la adecuada, la expansión y el windowing. La metodología de expansión requiere que todas las variables de fecha se vean incrementadas en su tamaño para alojar la información correspondiente al siglo. Con windowing, las variables permanecen en su formato original de dos dígitos. El siglo es determinado mediante una regla que utiliza un año de corte. Windowing ofrece como principal beneficio el poder evitar que la modificación de los archivos de datos heredados se haga necesaria.

10. Problema del Año 2000: un tema de negocios con implicancias técnicas.

Se trata de este interrogante de negocio: ¿qué porcentaje de los proyectos puede ser terminado a tiempo dado que la supervivencia del negocio está en juego?

Los ejecutivos deben convencerse de la gravedad del problema. Al reaccionar, se impulsará la reacción de arriba hacia abajo que el proyecto del Año 2000 necesita para ser exitoso.

El mercado de productos de "cura" para el Año 2000 vio llegar una gran cantidad de herramientas durante 1998, diseñadas para garantizar que las computadoras sean capaces de "saludar" el 1º de enero del 2000 como si se tratara de un sábado cualquiera.

Los usuarios son muy cuidadosos a la hora de elegir herramientas para el Y2K: ansían una herramienta capaz de probar, monitorear y arreglar todo el software y el hardware dentro de una empresa. Algo que le queda grande a cualquier producto.

TransCentury Office de Platinum Technology Inc., es un sistema que respondió bien al problema. Resultó elegido Producto del Año 1999 de Damation, consiguiendo un 28 % de los votos entre las herramientas para el Año 2000.

El segundo lugar, lo ocupó Y2K Studio, de Direct Hit Software, empresa que fue apoyada en un 26 % de los participantes. El producto es efectivo en el análisis de código, y su dispositivo de control de versiones es útil.

En tercer lugar se encontró Milennium Cross Check de Data Integrity Inc.; los usuarios de este producto señalaron que el aprendizaje y uso de esta herramienta son sencillos, permitiendo la corrección de millones de líneas de código en poco tiempo.

Luego se ubicó Milennium Key de RMM Inc.,con un 14 % de los votos.

El dispositivo de inventario de datos de TransCentury identifica y prioriza la corrección de datos críticos de las bases de datos más conocidas.

Su dispositivo de "cura" automática guía a los usuarios a través de un proceso de corrección y soporta a los paquetes de software más populares.

Su dispositivo de análisis de desarrollo de aplicaciones, permite identificar y corregir problemas en los lenguajes de programación más conocidos.

"Es una buena solución para organizaciones de mediano tamaño que necesitan herramientas para el Año 2000, pero que no pueden darse el lujo de hacer reingeniería de sus bases de datos, planillas de cálculos y otros procesos que utilizan información de fecha de dos dígitos", comenta M. J. Ruck, director de ventas y marketing de la firma Desing Data Systems que utiliza TransCentury Office para sus servicios.

Es un paquete que se ocupa de todo, desde la plataforma de hardware hasta el sistema operativo y la compatibilidad para el Año 2000 de las aplicaciones de oficina, llegando a la corrección de datos.

Tiene un costo de u$s 100 por puesto de trabajo.

Según una encuesta realizada a Gustavo Vignera, Technical Manager de World Wide CEO, el tipo de oferta que ha tenido mayor demanda en 1998 fue la actualización de los sistemas heredados compatibilizándose al Problema del Año 2000.

Muchas empresas aprovecharon la ocasión y actualizaron su software. Gran parte de los presupuestos se destinaron a estas problemáticas, y poco a la necesidad creciente de las áreas de negocios de las empresas.

Poco se ha invertido en innovación, todo se focalizó en un plan de emergencia, en el que las mejoras de los sistemas de comunicación intergrupos quedó postergado.

La gerencia técnica de las empresas y las gerencias de negocio saben que para lograr los objetivos de competitividad que se están vislumbrando, deberán centrar sus inversiones informáticas en tres pilares:

 

• Implantación de herramientas que permitan descentralizar los sistemas existentes;

 

• Creación de ambientes colaborativos, donde el conocimiento fluya a través de la empresa y no quede estancado en las personas convirtiéndolas en imprescindibles;

 

• Reformulación de las estrategias comerciales, el comercio electrónico no se ve como una amenaza aún, pero será una fortaleza para los que lleguen primero.

En una encuesta realizada a Carlos Di Paola, Gerente Comercial de Software América, manifestó que el Y2K ha sido un gran disparador de la demanda de aplicativos de gestión.

El cliente le otorga a las herramientas de desarrollo una notable importancia, Se buscan las más difundidas en el mercado, las más probadas, las que hayan mostrado evolución, pues se entiende que generarán menores costos de soporte y mantenimiento.

Las plataformas de sistemas operativos recomendadas, si se consulta a los gerentes que tienen aplicaciones de misión crítica, serían Unix AS/400 o mainframe, muy pocos recomendarían NT. Pero si se consulta sobre el sistema operativo al que está migrando la mayor parte de las empresas en Argentina, es NT la plataforma más recomendada.

"NT 5.0 es el sistema operativo con más futuro", manifestó.

El 10 de julio de 1997 las Direcciones Nacionales de Coordinación e Integración Tecnológica y de Estandarización y Asistencia Técnica organizaron, en el salón auditorio del Banco Hipotecario Nacional, la III Jornada sobre Modernización Tecnológica del Estado, referida en su totalidad a la Crisis del Año 2000.

------------------------------------------------------------------------------------------------------------------------------------------

Lo primero que debo decirles es que el que el material que les he entregado es para referencia únicamente. No traten de seguir mi presentación utilizando ese material porque no va a funcionar.

Lo segundo es que mi objetivo, mi rol hoy, no es entretenerlos, no es divertirlos, ni siquiera que yo les caiga bien. Creo que van a tomar en cuenta algunas de las cosas que voy a decir o quizá ni siquiera les guste la forma en que diga ciertas cosas. Pero mi único objetivo acá es simplemente que cuando se vayan quiero que verifiquen sus sistemas para ver si lo que les he dicho es cierto.

Ni siquiera creo que crean lo que les diga. De hecho preferiría que fueran sumamente escépticos. Porque alguien escéptico está haciendo la pregunta "demuéstremelo, demuéstreme que este es un problema". Por supuesto también habrá algunos cínicos en la audiencia. No puedo hacer nada. Los cínicos se han decidido ya antes de entrar a la sala, y por qué están acá desperdiciando su tiempo no lo sé.

Yo he estado hablando del problema durante seis años. El problema realmente es muy, muy simple: nuestros sistemas de computación fueron escritos para almacenar dos dígitos para el año en lugar de cuatro y debido a esto cuando ponemos 00 en esos sistemas, fallan.

Esa no es una predicción, es una observación. Es como sus sistemas están escritos actualmente. Es demasiado fácil de demostrar. Todo lo que tiene que hacer es ir a un sistema, ingresar 00 oprimir enter o adelantar el reloj al 01/01/2000 para ver qué es lo que pasa: los sistemas fallarán y las computadoras se detendrán. ¿Todas las aplicaciones de las computadoras se detendrán?. Por supuesto que no. Algunas personas supieron lo suficiente para hacer las cosas bien. Algunas personas escribieron sistemas después de que un (....) se volvió obsoleto y quién reconoce esto. Necesito verificar que la traducción esté funcionando así que les pregunto si la respuesta es sí quiere decir que la traducción está funcionando. Quién reconoce esto. Contra la pared pónganse. Porque nosotros somos aquellos a los que están culpando . Es una tarjeta y hay muchas razones por las cuales el problema del año 2000 existe y una se debe a esta tarjeta. No había espacio suficiente en esta tarjeta como para almacenar todos los datos que hubiéramos querido almacenar. Entonces qué hicimos, transigimos, cedimos, dejamos de lado dos dígitos. Pero no fue simplemente porque este papelito era demasiado chico. Sino también porque la administración, el management tomó la decisión que dice porque ingresar mil nueve, mil nueve todo el tiempo, por qué pagar por esas tipeadas adicionales, cuando los dos dígitos sirven por 30 años. Y la gente de computación, es decir algunos de nosotros fuimos a la gerencia y dijimos "esto no va a funcionar correctamente en el año 2000". Y la respuesta de la gerencia fue "no nos preocupemos por los problemas que van a darse de aquí a 30 años". Y diez años más tarde volvimos. Y dijeron "no nos preocupemos por los problemas que van a ocurrir de aquí a 20 años...,10 años..., 5 años..., preocupémonos más adelante". El más tarde, el adelante , ya llegó. Ya ha llegado. Tengo que mirar mi reloj, porque no puedo creer que es 10 de julio de 1997, y creo que quizá haya una o dos personas en esta sala, una o dos organizaciones que tengan un plan presupuestado para arreglar sus sistemas. Realmente me sorprende. Yo he estado hablando de esto durante seis años y llego al punto donde realmente no creo que haya empresas que no tengan un plan ya. Y a veces me olvido, se me acaba la esperanza. De alguna forma nosotros nos equivocamos, nosotros las personas que hemos tratado de comunicarles que el problema es real. De alguna forma la culpa es nuestra. Pero luego leo libros de historia y descubro que hemos estado aquí antes. Un libro muy interesante, una biografía de Winston Churchill, por William Manchester, y les voy a leer un párrafo, ojalá lo hubiera escrito yo: "cuando la situación era manejable, era dejada de lado. Y ahora que está fuera de control, (....) demasiado tarde los recursos que podían (...) en ese momento". No hay nada nuevo. Es tan viejo como la antigua edad. Y cae en ese catálogo largo, lúgubre, del fracaso de la inexperiencia y de la posibilidad de enseñarle a la humanidad. La falta de visión, la falta de voluntad de actuar cuando la acción podría ser eficaz. Y empecé a hablar de esto en 1991. Si hubiéramos empezado a resolver el problema en el ´91 lo podríamos haber hecho bien. Hoy estamos hablando de cosas que afectan a los compiladores, y que hacen un bypass en el código fuente donde podríamos hacer un truco con la computadora para que la computadora lo haga bien. La falta de pensamiento claro, confusión hasta que se de la emergencia, hasta que la autopreservación nos ataque. Estas son las funciones que constituyen la repetición incesante de la historia. Y esto podría salir de un libro o revista de computación hablando del problema del año 2000.

Yo sé que en Sudamérica ustedes han tenido mucha experiencia cambiando sus sistemas para adaptarse a los cambios en monedas de la noche a la mañana. Les sugeriría que si esos esfuerzos fueron realmente impresionantes, cambiar el tamaño de un campo en una moneda es algo significativamente diferente de lo que lo es tomar en cuenta información ambigua.

Porque de eso se trata el año 2000. Almacenamos dos dígitos para el año.

55 representa 1855, 1955 o 2055. Es ahí donde es exclusivamente diferente el problema que el del cambio de la moneda. Y mayormente, nosotros, realmente, no logramos encontrar el problema. Y esa es una frase estadounidense, una forma abreviada de decir no entendemos la amplitud y la profundidad del problema. La gerencia no quiere creer que dos dígitos ausentes puedan causar tantos problemas. Y este es un problema muy particular. Me lleva cuatro frases, cuatro oraciones, dos minutos describir este problema para un chico de 12 años y el chico sabe inmediatamente cuál es el problema, y ustedes también.

Cuando yo hago el cálculo de una fecha, que edad tengo. 97, el año de hoy, menos 55, tengo 42 años. En el año 00, el cálculo es exactamente igual 00 menos 55 , yo tengo menos 55 años. Un chico puede comprender eso. Y una de las respuestas inmediatas de un empresario que no comprende las computadoras es la siguiente: "usted se olvidó de los dígitos, simplemente vuelva a incluirlos. Qué tan difícil puede ser eso". Y esa es una respuesta completamente normal , y no puedo acusar a nadie, que a primera vista mire esto y diga "debido a que es simple de entender debe ser simple de solucionar". No es simple de solucionar.

A primera vista parece serlo, cuando uno levanta las tapas y mira los sistemas que escribieron su primera inclinación va a ser "oh, esto es sorprendentemente difícil" y a medida que mire más profundamente van a sorprenderse de la complejidad del problema. La gerencia o el management no quiere creer que este problema sea real. Ellos van a tomar cualquier información para confirmar esa creencia. Y hay mucha información para ellos.

El año pasado The Economist, una revista de negocios semanal, muy conocida, merece muchísimo respeto en los corredores de los más altos ejecutivos, tenían un artículo sobre el problema del año 2000, un artículo que su management quería escuchar: el grupo Gartner, al que vamos a escuchar después, ha estimado que esto va a costar 600.000 millones de dólares estadounidenses a nivel mundial. Y esta cifra es ridícula. Ellos hicieron el siguiente cálculo: dijeron que, a un salario promedio de 35.000 dólares de un programador (no tengo ni idea de dónde sacaron esa cifra), y dijeron que esos 600.000 dólares significan que cada programador tendría que trabajar todos los días de ahora hasta el año 2000 para solucionar el problema.

Por unos pocos segundos creí que habían comprendido el problema. La siguiente línea contradecía todo el argumento. Decían: dado que esto es inconcebible, la cifra debe ser incorrecta. Y su management, su gerencia quiere escuchar eso. Especialmente quieren escucharlo de The Economist. Pero no es sólo el Economist. El 26 de febrero de este año estuve en Londres y The Financial Times de Londres, un periódico bastante prestigioso escribió un editorial que contenía tres afirmaciones que su gerencia y su gobierno quieren escuchar.

La primera de ellas dice que las PC´s no se verán afectadas por el problema del año 2000. Para aquellos de ustedes que pensaban que tenían un problema en el mundo de las PC´s , no tienen que preocuparse porque el Financial Times les ha dicho otra cosa. Para aquellos de ustedes que han tratado de comunicar este problema a la gerencia, su respuesta es "acabo de leerlo en el Financial Times, no tenemos un problema en el mundo de las PC´s. Todo lo que quiere hacer usted es ganar dinero". La segunda afirmación: Hay un mito, por así decirlo, que este problema está exagerado, ampliado por gente como yo para generar una muy buena renta para nosotros. Y como dijo Gustavo (Del Pino, Director Nacional de Estandarización y Asistencia Técnica de la Sec. de la Función Pública) cuando me hizo esa pregunta ayer en el auto, mi respuesta fue muy simple: el hecho de que el cáncer hace a los médicos muy ricos, no quiere decir que el problema no exista. El problema es real. Me lleva 5 minutos demostrarlo.

En el artículo que expusieron, tenían una frase. algunas personas creen que esto no es nada más que excitación o exageración generadas por los consultores para aumentar los negocios. Y eso es lo que su gerencia quiere escuchar. Y la tercera afirmación, quizá la más importante. Ellos dijeron que si bien creemos que habrá algunos problemas, mayormente, nadie los notará. La gerencia quiere escuchar esto y hace muy difícil para una persona de informática, acudir a la gerencia y convencerlos de que necesitan una gran suma de dinero para solucionar su problema cuando el Financial Times les está diciendo "no se preocupe, esté contento".

Aquí hay algunas preguntas que el Financial Times necesita formular, hay algunas preguntas que la gerencia necesita formular y hay algunas preguntas que la industria informática necesita formular. En el mismo tono que el Financial Times, y debo ser justo con ellos, porque desde ese artículo ellos han cambiado su posición, se han retractado. E imprimieron prácticamente una disculpa en la primera plana del Financial Times diciendo que se habían equivocado. Ellos ahora son la fuente número 1 de artículos relacionados con negocios que se refieren al problema del año 2000. Ellos son el líder en noticias del mundo de negocios. Es decir, qué significa este problema para el mundo empresario.

Al mismo tiempo el Financial Times publicó un artículo sobre el National West Bank, que ha presupuestado 100 millones de Libras para solucionar este problema. ¿Cuántos de vuestros bancos han presupuestado para resolverlo?. Y aquí hay algunas preguntas que los periódicos deberían estar haciendo. Los bancos de EEUU han asignado montos similares, los de Canadá también. Algunos sistemas bancarios están conscientes de que el problema es real.

Aquí hay algunas preguntas. Pregunta número 1: Dado que nosotros creemos que esto es simplemente una moda, que es una exageración ¿por qué están gastando 100 millones de libras en un problema que no existe, qué han descubierto que es suficientemente importante para merecer un presupuesto de 100 millones de libras? Esto es una pregunta importante. Porque una de dos cosas son ciertas: o el Banco ha sido convencido por mí mismo o por otros consultores de que existe un problema cuando no existe, en cuyo caso los accionistas deberían decir algo con respecto a ese gran desembolso o, caso contrario, "encontraron algo, encontraron un problema". Un problema que no puede ser resuelto simplemente reemplazando y agregando esos dos dígitos que se habían dejado afuera.

Dicho sea de paso British Telecom ha presupuestado 350 millones de Libras, American Airlines 60 millones de dólares. Estas no son empresas que asignan este tipo de fondos porque sí. Lo asignan porque han descubierto algo suficientemente importante para merecer semejante desembolso.

La siguiente pregunta a cualquier organización que haya armado un plan es la siguiente: ¿qué pasaría si ignoran el problema, si simplemente no tratan de arreglarlo? A todas las empresas a las que les he formulado esta pregunta me dicen : "si nosotros no lo arreglamos, quebramos".

Y aquí es donde algunos mueven las cabezas y dicen "esto me parece una exageración". Esta es la realidad, los sistemas están destruidos. Una empresa del siglo XX existe con la computadora, sin la computadora no se puede hacer lo que uno necesita hacer, sin la computadora las empresas de aviación no pueden funcionar, los bancos no pueden transferir fondos, no pueden hacer los totales, las empresas de bienes inmuebles no pueden vender, las empresas tampoco pueden tener inventarios. Sin computadoras se para todo. Y le dirán en forma muy renuente que si esto no se arregla van a perder sus negocios. Y esto no soy yo el que lo dice, se lo dicen ellos. Tengo nombres de muchísimas personas de esas organizaciones e instituciones que les dirán precisamente eso.

Tercera pregunta: ¿cuándo fue la última vez que ustedes tenían proyectos en el departamento de informática que tenía un presupuesto de 100 millones de libras y fue completado a tiempo? Porque deben entender lo siguiente: terminar con este problema en forma atrasada es exactamente lo mismo que no empezar.

Mucha gente siente que esta pregunta es bastante graciosa, pero entonces yo les pregunto: ¿durante los últimos tres años, vuestra organización ha cumplido 100% de todas las aplicaciones informáticas en tiempo, dentro del plazo estipulado? ¿Han cumplido 80%?, ¿gracioso, no?. Siempre la gente se ríe. ¿60%?. No me interesa cuánto hayan gastado. Tampoco me interesa si excedieron el presupuesto en 5%. Quiero saber si lo cumplieron en tiempo. ¿60%?. No he visto nadie que levantara la mano.¿ 50%?. Entiendan lo que acaban de confirmar. Por favor comprendan lo que acaban de confirmar: No más del 50% de los aquí presentes tiene una probabilidad del 50% de entregar una aplicación informática dentro del plazo establecido. Entiendan por favor lo que me están diciendo, porque este proyecto es único, singular en un aspecto particular: Ustedes de ninguna manera pueden no cumplir el plazo. Pueden exceder el presupuesto, gastar todo el dinero que quieran, pero no pueden llegar tarde. Particularmente en las aplicaciones de misión crítica. Un sistema de misión crítica es uno que si no funciona ese día la empresa o la institución no puede funcionar, no gana dinero. En un gran edificio en EEUU, si el conmutador central se rompe, todos se van a su casa, la capacidad de hacer una llamada es íntegro al negocio de ganar dinero. Su uno impide esa posibilidad se detienen los negocios, uno no podría hacer absolutamente nada. British Telecom tiene un presupuesto de 350 millones de libras y me dirán que si no arreglan este problema no habrá tono de avisado en el Reino Unido hasta que sea arreglado.

Necesito que me den una información, porque exactamente no sé cuánto saben ustedes del problema del año 2000. Me han dicho algunas cosas que no quiero creer, entonces en lugar de creerle a alguien que me ha dicho algo les pregunto a ustedes: ¿cuántos de ustedes han terminado un inventario de todas sus aplicaciones? No tiene sentido hacerles más preguntas, si ustedes no saben cuántas aplicaciones tienen y tampoco tienen idea de cuánto es el trabajo a realizar. Hace un tiempo señalé que ustedes me acaban de decir que no tienen más del 50% de probabilidades de terminar un trabajo en tiempo. Acá hay una pregunta: ¿han abordado ustedes a la gerencia para explicarles que cuando llega la cuestión de entregar las cosas dentro del plazo establecido ustedes no lo hacen muy bien? ¿Entiende la gerencia bien este problema? ¿Hay algún apostador acá presente? Alguien que le guste ir al casino de vez en cuando. Tengo un juego que me gustaría que hagan.

Quisiera que alguien se acerque y me de 1000 pesos . Después otro me da una moneda. Por algún motivo nadie desconfía en la moneda que yo llevo. Y el juego que vamos a hacer es muy simple. Yo tomo la moneda, la tiro. Cara: usted recibe de vuelta su dinero. Cruz : yo me lo guardo. ¿Alguien quiere jugar?, ¿por qué no quieren? Porque es un juego bastante tonto. Sólo un idiota jugaría. La mejor posibilidad es irse con lo apostado. La mala noticia es que ustedes ya están jugando ese juego. Nuestra organización está ahí ya sobre la mesa. Y la moneda es vuestra capacidad de completar los sistemas para apoyar esa organización dentro del plazo establecido. Si arreglan los sistemas dentro del plazo pueden recuperar el negocio, y si no, fracasan, quiebra la empresa. ¿Su gerencia está consciente de que usted está jugando ese juego, la gerencia sabe que la moneda no es muy confiable, que a lo mejor el 10% de las veces van a poder cumplir los plazos establecidos?. Ese es el riesgo.

Estoy llegando a una etapa de mi vida en la que después de 6 años de decir exactamente lo mismo -igual que dijo Churchill-, no ha cambiado nada, la historia hoy es igual a la que era hace seis años: sus sistemas están inutilizados. En EEUU hay una frase y la he cambiado un poquito: ¿qué parte del 00 usted no comprende? Hay escasez de personas. En EEUU los sueldos están aumentando enormemente. No se puede conseguir la suficiente persona capacitada. Alguien alguna vez me dijo que quería un gerente del año 2000 y me preguntaron si yo estaría interesado. Le dije que preferiría hablar de eso a hacerlo. Me dijeron estamos dispuestos a pagar bastante. ¿Cuánto?, le pregunté. Lo que haga falta, me contestaron. Yo dije: con 300.000 dólares norteamericanos. ¿Está un poco sorprendido? "No", contestaron. Estaban dispuestos a pagarlos por un gerente del año 2000. Me dijeron que habían publicado avisos y nadie contesta, no queda nadie en EEUU. Yo les dije que vayan a Europa. Aún no han allí despertado al problema. Publiquen un aviso en Sudamérica. No han despertado ahí todavía. Hay mucha gente por ahí que tiene las capacidades para solucionar este problema pero que no han empezado todavía. Roben la gente que necesitan a otros países. Está ya empezando en Brasil. Están importando expertos de Brasil a EEUU. La gente me dice "entiendo que el problema es grave". En otras palabras, no se discute. Y para ser honesto , yo no tolero ninguna discusión. El problema es real y se puede demostrar. Las empresas que han estudiado esto han detectado el problema real que es más grande y más feo de lo que jamás han esperado. Me preguntan: ¿realmente, cuán grande es el problema?. Y mi respuesta es un tanto cínica después de 6 años y pido disculpas por algo de cinismo en todo esto. ¿Y cuán grande tiene que ser antes de que usted despierte?.

Si usted se va a suicidar y está buscando un edificio del cual se va a tirar, cuando encuentra un edificio de 10 pisos no hace falta que siga buscando uno más alto: 10 pisos es suficiente. El problema es lo suficientemente grande. No importa cuán grande sea. Empiecen hoy para arreglarlo. Algunos me dicen "entiendo que el problema es real pero después quisiera conversar cuándo debería empezar a arreglarlo". Vuelve a cuán grande es realmente el problema. y puedo dar una analogía cuando me hacen esa pregunta. (Dificultades de audio con el cassette. La analogía que De Jager realiza gira en torno a un hombre que tiene problemas con los bulones y tuercas de los neumáticos de su automóvil, que quedan desajustados. Aún así sale a la ruta con el autómovil junto a su mujer y va a una velocidad de 100 kms por hora. En un momento está por chocar. El hombre discute con su mujer si detener o no detener el auto, sabiendo que sus neumáticos están desajustados---sigue audio normal---) (...) ¿Y aún quiere establecer una discusión filosófica sobre si se necesita 75 ó 90 metros para detener el vehículo? Detenga el auto ya!! Si después de haber detenido el auto no lo han tenido que sacar con los bomberos, y quiere realmente ponerse a considerar cuánto le llevó, tomar un metro y medir la distancia... Pero no lo empiece con esa discusión. Empiece a trabajar en eso ya. ¿Qué es lo peor que les podría pasar si ustedes empiezan a trabajar para solucionar el problema de inmediato? Para algunos expertos en computación yo entiendo que es un concepto muy radical la noción de que uno terminaría por adelantado. Es algo inaceptable para la mayoría de la gente diplomática, pero eso sería lo peor que le podría pasar. Si terminara antes de tiempo, podrían volver y decirle pienso que usted se equivocó, lo hicimos en dieciocho meses, no necesitamos dos años, usted Peter es culpable de habernos advertido de antemano. Soy culpable, no vengan después a decirme en el año 2000, en marzo, diciéndome "usted no nos dijo que teníamos que empezar antes, usted no nos convenció, es culpa suya porque usted no nos convenció. El problema es real, ¿hay alguien aquí presente que no crea que este es un problema real? necesito saber levanten las manos por favor, bueno no hace falta que levanten las manos, el problema es real, una empresa como British Telecom ha invertido 350 millones de libras, ¿la industria de las telecomunicaciones acá que está haciendo, que presupuesto tiene, tienen un presupuesto, han empezado? La pregunta es la siguiente: si British Telecom, una empresa de telecomunicaciones con bastante renombre ha asignado y reconocido que existe un problema y que vuestra industria de telecomunicaciones no haya hecho lo mismo, ¿quién creen ustedes que debe tener razón?

Los bancos de EE.UU., Inglaterra y Canadá, todos y cada uno de ellos tienen un proyecto para el año 2000. Todos vuestros bancos tienen un proyecto en marcha, si no han puesto en peligro esta economía, si no es la responsabilidad del gobierno sacar una bandera roja y decir "momentito esto nos va a traer un problema porque no están haciendo algo que están esperando, o el problema del 00 ustedes no lo entienden", el tema es real.

¿Cuántos de ustedes han sido programadores, se que ustedes reconocieron esta tarjeta, cuántos acá han sido programadores y no programadores? El resto que no han sido quisiera que comprendan que los programadores que tengo acá y yo mismo somos las personas mas optimistas del mundo, es nuestra naturaleza así. ¿Alguna vez han hablado con alguien de informática y le presentan un problema y esa persona de informática le contesta eso no se puede hacer?, ¿qué responde una persona de informática a un problema que ustedes le presentan?, "no hay problema eso lo podemos arreglar, lo va a tener listo en dos semanas". Observen a la gente de informática cuando les diga lo siguiente; yo creo que no sólo son los más optimistas, el motivo para ser los mas optimistas es por nuestra capacitación.

Cuando yo estudiaba en la universidad en 1977/78, observen que yo digo siempre 1900 es algo como obligatorio particularmente por el tema que yo estoy hablando, cuando yo estaba en la universidad y estudiaba computación y durante las tardes el profesor me daba una tarea, a lo mejor una página, una instrucción para un programa, y durante el resto del día yo iba pensando el programa, como lo iba a escribir, iba a cenar y durante la cena sacaba un lápiz y ahí empezaba a escribir un diagrama de flujo, y tenía mucha confianza que esto lo iba a poder terminar a la seis, me iba a la sala de informática y había 3 tipos de máquinas, estaba la máquina donde se perforaban estas tarjetas, donde se perforaban, después se tomaban y se ponían en el lector de tarjetas, y después se iba a la impresora.

Se dan cuenta de la situación, ahora a las 8 de la noche, después de dos horas, más tarde, había un programa de TV que me gustaba mucho, que se llamaba El Prisionero. A las 6 me sentaba frente a la máquina perforadora y yo sabía que para las 8 de la noche mi proyecto iba a estar terminado y yo iba a poder ver el programa de TV que me gustaba en mi habitación de la universidad que era El Prisionero. Yo escribía 150 veces, la sacaba tomaba una lapicera, hacía una marca en diagonal por si se me caían podía ponerlos en secuencia , allá dicen que sí con la cabeza. Después iba al lector de tarjetas que se llamaba Jopper (?), se llamaba Jopper por (Greik) Jopper, se que hay algún juego de palabras que no funciona, un viejo problema de los EE.UU. Después íbamos, ahí presionábamos un botón y sonaba prrr, cuando se comía la tarjeta. Después pasaba a la impresora y yo siempre iba caminando sonriendo de oreja a oreja porque no sólo mi programa se procesaba bien en la primer corrida sino que también era correcto. En otras palabras, yo habría terminado en la primer corrida. Cuando espero que salga de la impresora, me sonrío de lado a lado, sale la impresión, y está lleno de errores. Yo estaba furioso, sorprendido de que a la computadora no le había caído bien lo que yo había hecho. Miraba la impresión, me iba al escritorio y cuando volvía descubría dónde estaban los errores, y decía "¡que bueno!, ya lo arreglé todo", y me sentaba para hacer la segunda corrida. Al preparar la nueva tarjeta la ponía en la lectora, recibo la impresión y salía sorprendido por segunda vez cuando otra vez había errores. Las cuatro de la mañana, yo sigo caminando hacia la impresora con una sonrisa en la cara. Esta corrida esta vez va a estar todo bien". Y aquí lo tenemos. Si yo como programador no podía continuar hasta las 4 de la mañana con un alto grado de confianza en mi capacidad de hacer esto bien, no me hubiera convertido en programador. En la corrida número 15 yo decía "olvidémonos de esto. Me voy a ir voy a cambiar mis estudios. Voy a ser un psicólogo". La Psicología "anormal" porque sé que tengo todo un grupo de clientes en esto de la computación, que van a necesitar mi ayuda. Y después, un poco más adelante, me hubiera convertido en un gerente de gente de computación. La gente de computación es la gente más optimista del mundo. Y, lo que le está diciendo la gente de computación a la gerencia actualmente, es lo siguiente: "No se preocupen, vamos a tener el problema del año 2000 solucionado para fines de 1998. Confíen en nosotros". Ahora, acá tenemos algo sorprendente. Las empresas que empezaron a hacer este proyecto 2 ó 4 ó 5 años atrás, todas volvieron a decir exactamente lo mismo: "no hay forma de hacer todo a tiempo". Estas son empresas que han estado trabajando dos años. "No hay forma de lograr hacer todo a tiempo". Las únicas empresas actualmente que dicen que van a tener todo listo para fines de 1998 son las empresas que aun no hicieron un inventario completo, un análisis de impacto completo, no consideraron sus recursos, ni el tamaño de la tarea, ni prepararon un plan proyecto, ni tomaron en cuenta el hecho de que los proveedores no cumplen, no han tomado en cuenta que su software, los sistemas operativos con los que trabajan no cumplen, no han tomado en cuenta que sus proveedores que les mandan datos aun no han solucionado su problema, no han tomado en cuenta que ellos van a estar comunicándose con sus clientes. Solamente esas personas están diciendo "vamos a terminar con esto antes de fines de 1998". Y eso es lo que la gerencia quiere escuchar. No vamos a decirles a ellos "tenemos el 50 % de posibilidades de cumplir con lo que hagamos tarde". nosotros ahora estamos en un momento en el que ya no tenemos tiempo de hacer todo, donde sólo hay tiempo para hacer las cosas de "misión crítica", recuerdan como los definí: las cosas que deben hacerse. Eso es todo lo que tenemos tiempo para hacer. Y eso se llama triage, que es un término médico del ejército, que se los voy a describir: algunas personas se sienten incómodas cuando yo describo que es triage porque se trata de un tema incómodo. Es un aspecto necesario, es decir que sea algo incómodo, molesto. Triage es una situación en la que un número de personas se encuentran en una situación militar y sólo tiene uno o dos médicos. Un médico solamente tiene un objetivo en la vida: salvar a la mayor cantidad de vidas posibles. Y, si estalla una bomba en esta sala, el médico los dividirá en tres categorías distintas: la número 1, los que tiene lesiones leves, nada serio, que si los ignoro dos o tres días todos van a vivir, "acá tiene aspirina, quéjense pero bajito, no me molesten, estoy trabajando". A otros les diría :"Usted no tiene tanta suerte, tiene lesiones múltiples, perdió miembros, tiene hemorragias internas, si trabajara con usted 10 horas hay muchas posibilidades de que muera. Lo lamento, aquí tiene morfina, vaya a morirse tranquilo, estoy ocupado". Y a otros les diría que "tienen lesiones, pero si les doy una o dos horas de mi tiempo, puedo salvar a cada uno de ustedes, ese es mi objetivo en la vida". Nadie toma esa decisión de manera liviana, nadie toma esa decisión y no tiene pesadillas, es una decisión muy dura. Tenemos que hacer lo mismo nosotros con nuestros sistemas. Necesitamos dividir nuestros sistemas en tres categorías. Para la primera categoría, tenemos que hacernos la pregunta ¿es una aplicación que si fallara me daría cuenta?, ¿Me importa si falla?. Toda organización corre sistemas a los que nadie les importa, realmente superfluos. Todos los tenemos. ¿y por qué corremos esas aplicaciones? Podíamos tener una buena discusión sobre el tema pero existen. Voy a ignorarlos, ni siquiera voy a ver si fracasan o no. Y si fracasan mala suerte. Acá de este lado hay sistemas que si fracasan serían muy, muy devastadores para mi empresa. Yo soy un viajero muy frecuente y a todas parte donde voy tengo la capacidad de sacar mi tarjeta de crédito, del cajero automático, ir a un banco poner mi tarjeta, ingresar unos números y sacar moneda local al mejor tipo de cambio. Y eso es algo que yo como pasajero frecuente realmente aprecio. Puedo estar en cualquier lugar del mundo y sacar dinero cuando lo preciso y eso es importante. No es lo suficientemente importante. Usted usa una aplicación que de no estar disponible me impide a mí poder beneficiarme de sus servicios como empresa. Para un banco el cajero automático es una tecnología muy importante, pero aun más importante que el cajero automático es sencillamente la capacidad de un cajero en el banco de ir a mi cuenta, ver cuanto dinero hay y entregarme el dinero. Si no puede hacer eso, entonces yo tengo un problema como cliente de ellos. Si ellos cierran los cajeros automáticos estaría un poco molesto, pero recurriría a llevar efectivo conmigo o a cheques de viajero, y el banco así no fallaría. Pero si el banco no puede rastrear dónde está mi dinero, va a fracasar, a quebrar. En triage lo que necesitamos hacer es definir dentro de nuestros sistemas cuáles son cruciales, cuáles sería lindos tener y cuáles son los que no nos importan, y enfocar todos nuestros esfuerzos hasta que se termine, hasta que se resuelva. Hacer otra cosa, va a ser considerado por los abogados como una culpa grave. Nuestra industria de la computación es una industria de moda. Dedicamos muchísimo tiempo preocupándonos por nuevas tecnologías y si hay tecnologías emergentes. Yo no sé cuál es la situación aquí en Argentina, sé que en EE.UU. todo el mundo está poniendo la página en la Web, y está habilitado para trabajar con Shar Haba (?), y demás. Aquí está la decisión. Ustedes tiene cinco programadores, dos aplicaciones, no tienen lo suficiente como para hacer ambas cosas. Uno es una página de la Web habilitada para Haba, y el otro es un sistema de contabilidad que no funciona debido al problema del año 2000. ¿Dónde asignan los recursos?. Tomen una decisión de negocios. Lo ponen en el sistema contable. Hacer otra cosa va a poner en riesgo a su organización. Ahora bien, la razón para que yo les cuente sobre el triage y describirles esa historia tan lúgubre, es la siguiente: nadie hace triage si cree que tiene otra opción en este problema. Entiéndalo : no hacemos triage si creemos, incluso un segundo, que tenemos otras oportunidades u otras alternativas. Solo hacemos triage cuando nos damos cuenta que de que no tenemos otra opción. La gerencia es la única que puede hacer un triage. Y con esto quiero decir no el gerente de informática. Si ustedes son gerentes de informática de un importante banco, ¿tienen la autoridad para decidir que el sistema de cajeros automáticos va a ser uno de los sistemas que van a ignorar?. La única gente que tiene esa capacidad son los directores del banco en la gerencia superior y sólo lo van a hacer si ustedes les comunican a ellos los verdaderos riesgos de este proyecto. Estamos quedándonos sin opciones y estamos creando situaciones bastante interesantes. Todo el mundo está dispuesto a señalar a los programadores y decir "dado que ustedes pasaron a dos dígitos en la década del 60 y del 70, es culpa de ustedes, tomaron una decisión equivocada, tendrían que haber sabido que eso no iba a funcionar en el año 2000. No lo tendrían que haber hecho". Pero lo hicimos por razones económicas. Hoy, ¿cuál es la situación?. Bien, hace dos años les hubiera dicho sin lugar a dudas que la única forma de solucionar esto es tomar todas las fechas y pasar de dos a cuatro dígitos. Expandir de dos a cuatro dígitos. No había ninguna otra forma de hacerlo. Era la forma correcta de hacerlo, la forma real de hacerlo y les iba a durar 8000 años. Hoy, no pasen a la expansión, no les queda tiempo. Entonces ¿qué estamos haciendo hoy?. Debido al hecho de que no tenemos el tiempo, no tenemos el dinero y no tenemos los recursos, ahora la solución es usar el Windowing (?), que es una solución de compromiso. Y yo conozco organizaciones que está usando el Windowing. Para aquellos de ustedes que no lo saben eso es simplemente hacer presunciones acerca de la fecha que uno mira. Por ejemplo, si están ingresando datos en el sistema, por ejemplo 01, podrían hacer que la computadora suponga que ese 01 es el año 2001, si el año es 25, podrían hacer que la computadora suponga que se trata de 1925. Entonces lo que tienen es si los datos son menores de 25, entonces es del siglo 21, si es más de 25, se trata del siglo 20. Entiendan que es una solución de compromiso. Entiendan cómo algunas personas han implementado esta solución: han hecho un código del handcode(?) del 25, el 25 fue incorporado al código de origen , al código fuente. Y esto es lo que va a pasar: en el año 2024 este problema va a reaparecer. Y vamos a volver a la gerencia y vamos a decirles "tenemos un problema del año 2025". "Y qué quiere decir con que vamos a tener un problema en el 2025". "Porque cuando lo resolvimos en 1998 usamos el (....) Windowing, por lo tanto pusimos la ventana Windowing en el 25 . Ahora llegó el 25, tenemos que ir a cambiar todo el esquema de windowing". Y la gerencia nos va a mirar y van a pensar que somos total y absolutamente estúpidos. En EE.UU. dicen que si el perro muerde una sola vez, mala suerte para el perro, si los muerde dos veces, es mala suerte para ustedes. Nosotros estamos usando soluciones de compromiso en nuestros sistemas hoy porque no nos hemos dado el suficiente tiempo como para hacer las cosas correctamente. Ahora hay una persona ahí afuera, no voy a mencionar su nombre, que está recomendando la siguiente solución: tomen el su código de objeto, que es la versión compilada del programa que corre directamente en la máquina, no es el código fuente, y debajo de eso coloquen otro programa que a medida que se dan los cálculos va decidir si el cálculo es un año, y si lo es va a cambiar la forma de hacer el cálculo sin que el código fuente lo sepa. Le va quitar el control al programador. ¿Se imaginan lo que sería testear esto para asegurarse de que funcione correctamente, o si hay un virus como los que hablo? Acá lo tienen. En 1999, si ustedes no han empezado, si no han solucionado esto, esto quizá sea la única solución que les quede. Quizá sea la única manera para que ustedes corrijan la situación. Es algo espantoso, en cuanto a programación, y va a causar enormes problemas. Pero ya no tenemos tiempo para solucionarlo. Creo que es responsabilidad de la comunidad informática acudir a la gerencia, explicarles los riesgos verdaderos. Porque entiendan esto: la gerencia no entiende una sola palabra, no entiende absolutamente nada de este problema. Están mirándolos a ustedes, buscando la verdad acerca de qué tan malo es el problema y cuáles son los riesgos. Y siempre y cuándo les digamos "no se preocupen, vamos a llegar para fines de 1998, confíen en nosotros, no es tan malo como ese maníaco de De Jager nos hace creer". Siempre y cuando sigan comunicándole eso a ellos, ustedes se están arrinconando, se están colocando en un rincón que se vuelve cada vez más chico. Y esto es lo que va a pasar en la mayoría de las organizaciones. Ustedes no van a aceptar mi consejo, no van a pedir a la gerencia, no les van decir que ustedes no pueden cumplir y así pasan las cosas en realidad. No es un comentario negativo contra nuestra industria. Es así nomás. Nosotros entregamos las cosas pero tarde. Es así como somos, eso es lo que hacemos. Nosotros cumplimos pero tarde. Así funciona nuestra industria. No deberíamos sentirnos ni orgullosos ni avergonzados, así son las cosas. Pero no vamos a convencer a la gerencia de esto. Y lo que vamos a hacer es intentar hacer todas las aplicaciones que queden afuera, vamos a tratar de solucionar todo. ¿Y qué es lo que va a pasar si tenemos un 60% de éxito en cuanto a entrega a tiempo?. Las cosas de misión crítica, son los programas que deben estar listos el primero de enero del 2000. Estos son las que me van a afectar, estas otras no me importan". Supongamos que son solo 100. A mediados de 1998 ustedes van a acudir a la gerencia y le van a decir "lo lamento, el 40% de nuestras aplicaciones van a llegar tarde, el 60 % va a llegar a tiempo sin embargo". Y la gerencia va a suspirar, ya lo escucharon antes "bien, bien, todo está bien siempre y cuando estos sistemas sean los que se cumplan". ¿Así ocurre? ¿Es así como los sistemas llegan tarde en base a prioridades o importancia? Lo que ocurre es que el 40% de esos van a llegar tarde, el 40% de estos van a llegar tarde, el 40% de estos otros van a llegar tarde también. Y el 40 % de esos que llegan tarde van a matar su organización. Y ellos no van a entender sus excusas, ellos simplemente no van a comprender que ustedes no les comunicaron a ellos los riesgos de este problema. Y una vez más alguno de ustedes quizá diga que estoy exagerando el caso, que yo estoy exagerando la importancia de este problema. Recuerden que el problema es real y cualquier persona de computación les dirá que es real y el peor error posible sería resolverlo temprano, anticipadamente. Ese es el error más grande que podrían cometer, resolverlo, pero anticipadamente. A mí me preguntan ¿qué pasa con una bala de plata? .Una "bala de plata" quiere decir una solución mágica. ¿Nadie podría resolver esto de alguna forma, no hay alguien que lo pueda hacer? Cuando un lego, una persona no técnica dice "¿no podrían encontrar alguna forma de resolver en la computación?", lo que quiere decir es lo siguiente: algo como un virus, que pondrían en la computadora un viernes a la tarde, que todo el mundo se vaya a casa, entra, hace todo lo suyo y el lunes a la mañana no tienen el problema ya. Eso es lo que la gente quiere decir cuando dice "¿no podría encontrar una solución mágica?". Supongamos que durante cinco minutos, porque es el tiempo que yo puedo retener el aliento, que una solución como esta existe. En otras palabras, para aquellos de ustedes que no están en la computación los programas están compuestos por dos partes, el código fuente, que son las instrucciones a la computadora que ustedes pueden entender, y eso se compila a través de algo que se llama compilador y pasa a algo que se llama módulo de objetos, que no es más que unos y ceros que la computadora puede entender. Esas tres partes son necesarias y la más importante es el código fuente, porque si quieren hacer un cambio en el módulo de objeto tiene que cambiar el código primero. Si alguien empieza a cambiar directamente el módulo es un loco, tendría que estar encerrado en alguna parte. Supongamos que yo tengo una "bala de plata", una solución mágica. Todo lo que tengo que hacer es traer el código fuente a la pantalla de la computadora, tomar mi "bala de plata", golpearla tres veces, clickear mis talones, decir "abracadabra" y el código queda totalmente cambiado. Y ni siquiera tiene que ser testeado. Ahora, entiendan que esto es una fantasía, no hay una cosa posible como esta por muchas razones, pero supongamos que sí es posible. ¿Yo resolví el `problema del año 2000? Ni siquiera me acerqué a él. Y ahora les voy a decir porqué. Para poder aplicar mi "bala de plata" tengo que tener el código fuente. En otras palabras, primero debo hacer el inventario, cuántos programas tengo. Ustedes en Argentina quizá estén bien porque han tenido que ir a sus sistemas para hacer cambios de moneda o el tipo de cambio. Bien podrían saber cuáles son los sistemas que tienen y usan diariamente. Ustedes son inusuales en ese sentido. En EE.UU. nunca tenemos que hacer eso, pero van a tener que hacer el inventario y eso lleva entre tres y seis meses de esfuerzo. Tiene que recopilar todos los sistemas. ¿cuántos de ustedes tienen el código de fuente para todos sus sistemas? Una. Dos manos. La mayoría de las organizaciones han perdido el 5% de su código fuente. En otras palabras en el módulo fuente corren el programa diariamente pero no tienen forma de cambiarlo. Esto no es inusual. 5% del código fuente se ha perdido. O sea que lo primero que hay que hacer es recrear ese código. Tienen que volver a escribir todo el programa. Es como volver a escribir estas tarjetas. Después deben compilar lo que han escrito y testearlo para asegurarse de que haga lo que hacía el programa anterior. La "bala de plata" no lo ayuda en nada en esto. Lo siguiente es que deben asegurarse de que el código fuente que ustedes tienen esté sincronizado, esté bien conectado con los módulo de objeto que existen. Para aquellos que no son técnicos, tienen que. (...) nuevas limitaciones, nuevas reglas, de manera que si uno toma códigos que no han sido compilados durante tres o cuatro anos, y se pasa por un nuevo compilador, no necesariamente puede compilarse para obtener el modelo de objeto. O sea que lo que hay que hacer es cambiar esto para asegurarse de que se pueda compilar y después realizar todo un proceso de prueba. Una vez que se tiene todo el código puede ser sincronizado con los modelos objetos que actualmente se utilizan, puede aplicar esta suerte mágica a todos los programas que tienen todos los sistemas y ni siquiera hace falta probarlo. Esto es una doble fantasía, siempre hay que probar todos los cambios que se realizan. Pero hay otra cosa adicional que se tiene que tomar en cuenta, solo pueden aplicar "bala de plata" a todos los programas que ustedes controlan, a todos los programas y el software que ustedes hayan comprado a proveedores, deben asegurarse que ellos han hecho que sus sistemas cumplan con los requisitos para ( ?) , y deberán esperar que ellos les entreguen los sistemas de ellos a ustedes y recuerden que ellos son parte también de la industria informática, de manera que la fecha que ellos les digan para mandarles las versiones actualizadas de sus software, de su hardware cambiarán. Es improbable que ellos cumplan con los plazos establecidos y es muy probable que ellos lleguen tarde.

Si alguien le dice que le van a entregar algo en el segundo trimestre de 1998 no se sorprenda si está en el tercer trimestre de 1998 y todavía no lo ha recibido. Hay otra cosa que también deben comprender, mientras se están haciendo todos estos cambios, todo el sistema operativo, todos los utilitarios, todos los paquetes de software que corren por encima de ellos, todos deberán ser reinstalados, hay que hacerles el actually cuando ,los proveedores entregan las nuevas versiones. Un ejercicio que es instructivo para muchas organizaciones es el siguiente: Cuantos paquetes de software se han comprado, cuantos utilitarios, cuantos sistemas operativos se utilizan, cuanto tiempo le llevo la última vez para hacerle el ...?...de uno al otro. Porque van a tener que hacer otra vez todo ese trabajo, y no es un trabajo insignificante.

Otra cosa que ocurre con bastante frecuencia es lo siguiente: Supongamos que ustedes tienen un paquete de contabilidad de un proveedor y compran ese paquete hace siete años. La primera versión hacía todo lo que ustedes querían, durante los años siguientes ellos pasaron de una versión a otra. Ustedes hicieron el updated como ellos lo hicieron? La mayoría de las empresas no lo hacen, de manera que puede haber siete versiones adelantadas a las que usted tiene. Para hacer un up..?., de una versión a otra con siete versiones de diferencia es un trabajo enorme. Recuerde que ustedes no pueden controlar este código, tiene que aceptar el que les da el proveedor. Ustedes pueden tirar todo lo que tienen y hacer desde cero la instalación, o hacen todas las instalaciones que hacen falta. Lo que estoy tratando de decir es que este es un problema diferente a cualquier otro que hayan tenido antes, aún si tuvieran una poción mágica y pudieran cambiar el código, no elimina el 90% del trabajo que hace falta hacer. Y la idea de que no se deben hacer pruebas después de que se hayan hecho cambios en los códigos es totalmente incorrecta.

Las pruebas se suponen que requieren el 50% del proyecto, estamos en julio para fines del 98 deberían haber terminado. Entonces así pueden ver un año entero de como funcionan los ciclos del programa de sueños que cae, ver como funciona, porque todos los cientos de miles de cambios que han realizado puedan ser estudiados y analizados para asegurarse de no estar en una situación crucial. Habrán de terminar antes del año 98, estos son 18 meses de pruebas, o sea que, 9 meses antes que terminen de hacer todos los cambios en el código. Yo le he dicho a la gente que empezar noviembre de este año, y ya no trataré de convencer a nadie que deben estar haciendo este cambio. Yo simplemente voy a decir que supongo que ustedes ya tienen el inventario completo, que han hecho un análisis de impacto, que tiene un plan de proyecto implementado con los recursos para implementar ese proyecto y que tiene la financiación completa para eso. O sea que ustedes ya tienen el dinero en una cuenta bancaria para poder gastarlos, esta va a ser mi prescripción básica a partir de noviembre de este año. Yo ya no puedo creer que ninguna organización que deje esta decisión mas allá de noviembre del 97, va a poder tener éxito.

Hace muchos años me preguntaron: estamos en la zona negra? Es decir, si no se empezó, se puede terminar? Y en ese momento yo dije nunca pensé acerca de esa pregunta, todavía no estamos dentro de la zona negra, en noviembre de este año creo que vamos a estar en la zona negra para la mayoría de las organizaciones que no han comenzado. ¿Quién de ustedes tiene iniciado un proyecto para el año 2000? Por favor, aunque me mientan levanten una sola mano. En Estados Unidos la situación, para darle un pantallazo de todo el mundo, yo voy a decir que un 35 % de las empresas tiene un plan para el año 2000. Con esto yo tengo una decisión muy estricta de lo que estoy diciendo, o sea que ya se ha hecho un inventario y se sabe cuanto hay que modificar. La mayoría de las organizaciones no tienen idea de que es todo lo que tienen. Abraham Lincoln, uno de los presidentes de los Estados Unidos, una vez se le hizo una pregunta muy interesante: Que longitud debería tener la pierna de un hombre? y lo que respondió fue muy simple: lo suficientemente largo para llegar al suelo. Cuantos programas tienen ustedes? No se, Tenemos los suficientes para hacer lo que hacemos. No tengo idea cuantos, pero tenemos suficientes programas para poder trabajar. Esta es la situación en la mayoría de las organizaciones, no tienen idea de cuantos programas tienen, saben que tienen suficientes. Pero hasta que uno no sepa cuantos programas tiene no puede responder a la pregunta, acerca de si está cumpliendo los requisitos para el año 2000, si está preparado para el año 2000 porque no han analizado cada uno de los programas. Esto es lo primero: el inventario. Segundo es el análisis de impacto que les mencioné. Este análisis de impacto le indica dos cosas, primero cuando van a caerse los programas. Cuando hablamos con la prensa debemos hablar en bit? de sonido, no tanto por el limite de atención que tiene una persona inteligente, sino porque están en la televisión y solo dan 5 segundos para comunicar una idea muy importante. O sea que siempre hablamos del 1° de enero del año 2000. ¿Cuántos de ustedes ya han experimentado un problema con el año 2000 con respecto a los sistemas? En este caso todos deberían haber levantado la mano. Y si no la levantaron significa simplemente lo siguiente: se han producido errores que ustedes no han identificado correctamente como programas del año 2000. Una vez que empezamos a identificar cuáles son los problemas del año 2000, uno dice si eso me pasó. Si usted abre la billetera o la cartera y mira la tarjeta de crédito, verá cómo el problema ya lo ha afectado. La tarjeta de crédito tiene como fecha de vencimiento, un año de dos dígitos como fecha de vencimiento. Si usted sacó una nueva tarjeta de crédito este año, la fecha de vencimiento debería tener un 00 que es un ciclo de tres años, o un 01 que es un ciclo de 4 años. Visa internacional había distribuido una gran cantidad de fecha de vencimiento 00 durante este año. Cuando esto llegó al público, los usuarios fueron a los negocios y se pasaban la tarjetas por la terminal de los negocios, esta terminal rechazaba la tarjeta. La terminal en el negocio le decía que la tarjeta estaba vencida. Visa tuvo que enviar todas las tarjetas otra vez con la fecha de vencimiento de 1999. Algunos dijeron esto no es un problema muy grande, es una solución pequeña, o sea que esto se puede solucionar cuando surgen los problemas. Pero el costo que tuvo Visa proviene de dos fuentes diferentes: primero varios millones en costos de correo, esto le costó varios millones de dólares. Hay alguna organización aquí presente para la que algunos millones de dólares no significan mucho, si ese fue el caso, saquen la tarjeta y mándenme unos cuantos cheques. El problema segundo es el siguiente: supongamos que Visa tiene 6 millones de tarjetas, una sexta parte de ellas son renovadas anualmente, si es del ciclo de 4 años, el 25% se renueva por año. Entonces si ustedes toman las que vencen el 00 y las pasan para el año 99, habrán duplicado el trabajo para 1999, y habrán reducido a 0 la carga de trabajo en el año 00, que hoy es un tema de recursos humanos bastante difícil de manejar. Nosotros tenemos problemas permanentemente. Algunos nos dicen que el problema del año 2000, es en realidad nada importante. Simplemente un problema de mantenimiento que no nos va a afectar hasta el año 2000 y cuando ocurra no va a ser muy importante. Como les dije, cuándo hablamos con la prensa hablamos como el 1° de enero del año 2000 y ya vemos que existen todo tipo de problemas. Recibí ayer un fax, yo recibo información muy curiosa en la oficina, parece que existe un diccionario financiero. Hay algún banquero aquí presente que me pueda explicar que es un ..(lift)..? Es algún tipo de oferta de compra o de venta de un instrumento financiero y tiene una duración de unos 3 años. Recibí un fax que me explica que uno de las grandes empresas de informática que maneja este tipo de transacción, no puede manejar estas transacciones de lifts? que venzan en el año 2000.O sea que le voy a pedir a todos los brokers que no utilicen esta herramienta hasta el año 2000. El tema es que esto es como decirles que hay una cantidad de clientes que ya no podrán atender, porque la computadora no puede manejar este tipo de transacción.

O sea que ya estamos enfrentando este problema, y a medida que sigamos en el futuro, la velocidad a la cual se produzcan estos problemas va a aumentar significativamente. La gente dice: Peter como será el primero de enero del año 2000? Creen que porque me parezco a Moisés puedo predecir el futuro. Yo no puedo predecir el futuro, me resulta sumamente difícil predecir como va a ser el asunto. Pero he estado tratando de obtener cierta idea de que va a ser en este momento. 1996 fue un año bisiesto, el año 2000 también va a ser un año bisiesto, cualquiera que quiera discutir esto, nos podemos reunir afuera. El año 1996 fue un año bisiesto, algunos programadores se equivocaron. Algunos de nuestros programadores no son demasiados brillantes, se equivocaron. Hubieron varios errores causados porque no pusieron el año 96 como año bisiesto. Hubieron muchos problemas con respecto a ese año bisiesto, pero algunos fueron suficientemente importantes para llegar a la prensa. El 2 de enero del año 1997 la bolsa de New York tuvo que cerrar dos horas por un problema relacionado con el año bisiesto 1996. El costo fueron varios millones de dólares que perdieron comisiones. Cuando no se podía operar en esa bolsa, la gente fue a operar en otra bolsa y perdieron comisiones. El 31 de diciembre de 1996, en Nueva Zelanda, hay una fabrica que procesa aluminio. Tenía mucho aluminio en la cinta transportadora, la computadora pensó que había llegado fin de año y cerró aunque se estaban produciendo grandes cantidades de aluminio. Dos horas mas tarde en Tasmania, con una diferencia horaria de dos horas, otro ramo de producción que tenía exactamente el mismo programa, apagó por el mismo motivo, eso causó 1 millón de dólares para arreglar todo ese aluminio que se había solidificado en las cintas transportadoras. En Australia hubo un dispositivo de almacenamiento, un disco rígido, que adentro en el microcódigo en uno de los controladores, tenía un problema con el año bisiesto. Esto causó un montón de problemas durante varias horas hasta que finalmente descubrieron que era lo que pasaba y pudieron arreglarlo. Hubo una Lotería, en Estados Unidos, que tuvo problemas porque había una situación con un banco. Hubo 5 problemas del año 96 por ser bisiesto que no fueron informados. En el año 2000 como va a ser, el problema del año bisiesto del 96 fue inesperado, no hay motivo por el cual haya sucedido. Sin embargo había 5 problemas lo suficientemente graves para llegar a la prensa. El problema del año 2000 es grande, eso lo sabemos, cualquiera se lo puede decir, hemos tenido muchos fracasos por eso. Y que tantas mas posibilidades o cuantos mas problemas habrá debido al problema del año 2000, que es lo que lo sumó para el año bisiesto. A partir de 70 problemas muy bajo, 100 demasiado bajo, 1000 muy bajo, 10000 conservador, yo digo que va a haber 10000 veces mas incidentes, habrá por lo menos 50000 problemas a nivel mundial. Mis amigos que están en este negocio dicen: no, esto es local, habrá por lo menos 100000 veces la cantidad de problemas. Acá hay una pregunta para ustedes: Cuando nosotros éramos jóvenes jugábamos a un juego llamado la casa de las cartas: tomábamos las cartas y hacíamos una casita un castillo, y esto es lo que estamos enfrentando. Cuando llegue el problema del año 2000, algunas empresas van a intentar solucionarlo a medida que se va cayendo. Vamos a intentar arreglar nuestra casa a medida que se va derrumbando. Otra analogía y los dejo: solucionar el problema es como encontrar una aguja en un pajar.

Hay 3 formas de encontrar una aguja en un pajar: Numero 1 con imanes, olvídense de eso, la otra forma es tomar cada pajita y mirarla y decir: es usted una aguja, y si lo es dejarla a un lado y si es una pajita tirarla, eso es lo que les recomiendo hacer. Y si pueden encontrar un imán que les ayude, usen decididamente el imán. Y hay una tercera forma, que se basa en lo que ustedes me dijeron hoy en cuanto a que tan adelantados están en resolver este problema, y creo que la mayoría de ustedes está contemplando precisamente eso. La tercera forma de encontrar la aguja en el pajar es la siguiente: desnudarse , saltar al pajar y jugar, darse vuelta, tirarse y orar que cuando encuentren la aguja. Muchas gracias.

Si uds. no han empezado ya, mañana su problema será 0.1% mayor de lo que es hoy. Habrán perdido un día de los 903 que quedan para el 2000. Si uds. esperan diez días más, el problema será un 1% mas grande y eso continuará. Ojalá pudiera hacerles una pregunta y recibir una respuesta. Si uds. no han empezado hoy, cuál es aquella cosa que necesitan escuchar de parte de alguien que los va a convencer para comenzar? Cuál es la cosa que los va a convencer de que esta es su prioridad número uno, que todo lo otro que hagan en el mundo de las computadoras es secundario. A mi me hacen esta pregunta todos los días. "Peter, como convenzo a la gente y les digo, ¿porqué me preguntan a mí? yo he estado hablando durante 6 años y uds. aún no han empezado...". Es obvio que yo no sé que decir. Algunos de los oradores hoy fueron muy honestos. Dolorosamente honestos. Yo advertí a la gente que yo no me paro acá para hacerme amigo de uds. o asustarlos. Yo simplemente "levanto" los sistemas de computación y les digo "miren aquí adentro" y si eso los asusta bueno... bien, pero yo no los asusto, esto los asustó. En la presentación, esta mañana, luego de mi charla, fueron uds. los que me asustaron a mí y se supone que no debería haber sido así. Yo soy el invitado... Con el debido respeto, si uds. tienen fechas límites programadas para 1999, no entienden el problema. Las fechas límites 1999 no son aceptables. Yo sé lo difícil que va a ser hacer esto para 1998, lo entiendo, quizás lo entiendo más que uds. mismos, sé lo difícil que va a ser trabajar con los gobiernos, para conseguir el dinero y cambiar las reglas a tiempo, para que esto se haga. Pero los límites que vencen en el 99 no van a funcionar, por dos motivos: 1) la que le contamos a todos, el motivo por el cual hay que terminar en el 98 es para poder ver todo el sistema funcionando luego de haber hecho cientos de miles de cambios en él. Esa es una buena razón. La otra es la que generalmente no divulgamos, no damos a conocer. El motivo es que como consultores no tenemos ninguna fe en nuestra capacidad o en la capacidad de los demás en la industria de la computación de cumplir con algo a tiempo. Nosotros decimos, "terminen para 1998" sabiendo que van a llegar a mediados de 1999. Si tienen un límite a mediados de 1999, esa fecha limite se les va a escapar al igual que todos los otros plazos, por los mismos motivos que se les van a escapar, no porque sean malos o incompetentes o porque no tengan problemas reales, sino que se van a desplazar por que va a haber un huracán, o porque va a haber un incendio, o porque su colaborador número 1 se le fue o fue contratado para otra cosa, o el proveedor no cumplió o porque hubo una epidemia de gripe... va a ser tarde por un millón de motivos distintos. Y la única regla que no puede quebrarse es que no pueden llegar tarde. En EE.UU., tenemos un santo, a pesar de no ser un país muy religioso, tenemos un santo que es Saint Murphy (risas). Es el santo patrono de todos los proyectos y créanme: él va a estar de guardia durante este proyecto! Es bueno que podamos reírnos de esto porque vamos a tener que reírnos mucho... ¿Cuánta gente va a tener vacaciones el año que viene? Pónganse serios! Este es el último año para los que saben algo de computación, podrán tomarse vacaciones. No hay más vacaciones hasta que corrijamos esto! Uds. no pueden enfermarse! Sus padres no podrán morirse! No podrán tener niños! Nada! No podemos llegar tarde! Pero uds. saben como yo, si son honestos consigo mismos, que cualquier plazo que uno fije va a retrasarse. Tenemos que planificar tomando en cuenta una falla, yo no soy pesimista, pero tenemos que ser racionalmente optimistas. Por cada plazo límite que uds. fijan tienen que hacerse la pregunta "qué pasa si llegamos tarde?" porque de alguna forma todo lo que hacemos hoy día, pagos, servicios, etc. seguirá teniendo que estar disponible, los bienes, los alimentos, etc. no puede no ocurrir.... Algunos de uds. van a decir "Pero Peter, estamos siendo realistas con este problema" y con eso paso al resumen. Me dieron (los organizadores de la jornada) las evaluaciones (evaluación de la jornada). Me dijeron que uds. son personas con sentido común y del humor. Espero que aprecien el mío...

Pregunta número 2: su organismo o empresa a comenzado a trabajar para solucionar el problema del año 2000? Sé que tienen sentido del humor. El 37% dice que "planeamos esperar a un futuro próximo", es decir, mañana. El 10% dice hemos terminado nuestra fase de evaluación, para mí eso significa que el 10% de uds. ha terminado de evaluar y que recién ahora entienden el problema. Otro 8% dice "no sólo hemos terminado con la evaluación sino que empezamos con la corrección". No voy a contradecir ninguna de estas cifras. Pero sí voy a enfrentar las cifras y voy a decir si tienen sentido. Empezamos con la fase de corrección. El 27% dijo "no, no hemos tomado ningún paso". El 17% dice no sé... no tengo ni idea... Sólo el 18% de uds. ha hecho una evaluación. La pregunta siguiente es divertida: El impacto del año 2000 sobre su organización será: 30% dijo alto impacto. 38% dijo medio. 26% dijo bajo. El 6% dijo "no sé".

Les voy a explicar una cosa, estas tres cifras no pueden ser superiores a este número (numero anterior pregunta). Entienden lo que les digo? Hasta que no hagan la evaluación no tienen fundamentos o bases sobre la cual decir cuál va a ser el grado de impacto sobre su organización. Sólo ese 18% que hizo la evaluación podrá decir si el impacto será bajo o alto. El resto francamente, no tiene la información por que no hizo la evaluación. Claro, alguno de uds. dirá "no es tan así"..., pero lo lamento, eso es lo que significa para mí! Pero está bien, recuerden, uds. son las personas más optimistas del mundo, son programadores... Yo no esperaría nada diferente de ninguna otra audiencia del mundo, esto es lo que esperaría... Y no es que esté mintiendo. Es que uds. son optimistas, tienen fe en sus propias habilidades. A veces están mal ubicados, es por eso que a veces llegan tarde... (detalla los números del panel pero no se entiende correctamente). Cada vez que se hace este tipo de encuestas, en cualquier parte del mundo, en Inglaterra o en los EE.UU., si el 59% dice "sí, nuestros sistemas se verán afectados", si seis meses después volvemos a hacer la misma encuesta, ese número siempre sube, nunca baja. En ninguna de las encuestas secuenciales que yo ví ha bajado. Mi propuesta a los organizadores es que de acá a seis meses envíen la misma encuesta y les pida que evalúen una vez más. Y les voy a hacer una predicción: el 59% subirá al 72%. Si lo hacen dentro de un año, subirá al 92%. La experiencia nos dice que cuando llevan un largo tiempo trabajando en este problema, descubren que el 90% de sus sistemas corren riesgo. No, el 59%. "¿Pueden existir consecuencias legales negativas para su organización si no se llega a tiempo con el problema del 2000?", fue otra de las preguntas. El 59% dijo si, 24% dijo no, 18% dijo no sé. No sé cuál es la situación jurídica acá, pero sé que en EE.UU. los van a demandar por cualquier cosa... Si uds. suben a mi propiedad y está lloviendo y uds. tienen puesto un traje nuevo... ahí se acabó porque la lluvia en mi propiedad arruinó su traje... así que EE.UU. está loco. Hemos tenido 5 demandas distintas que apuntaban a mí por las cosas que yo he dicho, a la gente no le gustan las cosas que yo digo. (Lo siguiente que lee De Jager son ítems de una encuesta) "¿En su organización el problema del año 2000 podría representar una demora en los planes de desarrollo?" 17% -verán que este número va a subir) "Una oportunidad para revisar los sistemas" -Me encanta el optimismo- 39% dijo sí... 40% dijo ambas. Hay una oportunidad para revisar lo que hemos hecho y hacerlo mejor. Es lo que yo llamo beneficios colaterales, accidentales, residuales. Al final de todo esto, si no hemos aprendido algo sobre cómo hacemos la computación, entonces no aprendimos nada con este proceso. "Su organismo o empresa ha reservado una partida presupuestaria para atender este problema?" 13% dijo si, 53% dijo no, 34% dijo no sé. Si vuelvo dentro de 3 semanas me gustaría que ese "no" haya bajado al 3% porque este problema no va a desaparecer. "Cuál sería el gasto que demandará el problema en su organismo?" 15% dijo menos de 100 mil dólares. Entre 100 y 500 mil dólares, 5%. Entre 500 mil y 1,5 millones 1%. Entre 1 millón y dos millones, 4%. Más de 2 millones, 2%. No lo sé, 73%. Ah... el 73% y el 18% está más o menos bien. Estamos siendo honestos. No hicimos la evaluación, cómo podríamos saber cuánto dinero nos costará. Pero al mismo tiempo si estamos diciendo que no sabemos cuánto dinero costará, estamos diciéndole a la gerencia "no se preocupe, vamos a solucionarlo para fines del 98, no tengo ni idea de cuánto es la cuenta, no tengo ni idea cuantos recursos tenemos ni de cuáles son los problemas que vamos a encontrar, pero no se preocupe, confíen en mi, para fines del 98 todo estará solucionado...". (sigue leyendo encuesta) "Para encarar el problema del año 2000 cuál de las siguientes frases refleja mejor su opinión: existen recursos suficientes: 41%; se contratará personal temporario 17%; -esta cifra es bastante frecuente- vamos a tercerizar, 32%". Y mi pregunta es, yo les acabo de decir que todos los países a dónde voy, todas las audiencias a las que me enfrento me dicen que ellos van a tercerizar el problema. Entonces vamos a tener gente suficiente porque estamos tercerizando. Sugerencia: llamen por teléfono a la persona a quien le van a dar el trabajo y pregúntenles si ellos tienen recursos suficientes para hacerse cargo de su trabajo, considerando que el 30% de esta sala planea enviarles el negocio. ¿De dónde creen que van a sacar la gente? Van a estar llamando a su gente preguntándole "quieren venir a trabajar para nosotros?". Acá va una sugerencia, en realidad son dos. Cuando nosotros armamos un plan de proyecto, cuántas horas productivas diarias planifica? Seis horas, no? Si Ud. logra seis días de trabajo de cada trabajador, eso es más o menos lo que se puede esperar. Alguna vez han planificado la rotación, es decir, qué porcentaje de personal perdería en un período de seis meses? En ninguno de los proyectos en los que yo he participado, jamás planificamos una rotación. En este proyecto, parte de su plan debe considerar que cada 6 meses uds. van a perder el 30% de su equipo. Dónde se iría? No sé, Unisys está consiguiendo gran parte del negocio, IBM también.... de dónde creen que consiguen la gente para trabajar? Están llamando a su gente y preguntándoles si quieren trabajar para ellos "Recién acabo de conseguir este contrato grande y no estoy con la gente suficiente" es lo que dicen todos los proveedores. Otro consejo, es que si uds. quieren que esto sea mucho más fácil, no se roben gente entre uds. porque si aún no tiene plazos muy concretos y tiene por ejemplo 10 personas trabajando en su equipo, viene alguien y le roba a 3 de sus mejores programadores, ¿cómo reacciona Ud.? ¿cómo vuelve a encarar el trabajo? O creen que por algún motivo eso no le va a pasar a Ud.? Cuál es la diferencia entre el programador que trabaja para el sector público y el que trabaja para el privado? Cuál es la diferencia en cuanto a salario? Principalmente los gobiernos dicen "Ah, pero Peter nuestra gente dicen que se quedan con nosotros en el Estado porque reciben beneficios adicionales tienen seguridad a largo plazo y otros beneficios. Se quedan por la seguridad que les ofrecemos". Sí, digo yo. Hasta cierto punto. En Canadá hay una historia que se publicó en una revista, y dice que había un programador en la provincia de Vancouver, que trabajaba para el gobierno provincial y ganaba 35 mil dólares canadienses como analista programador. Uno de los proveedores le ofreció un trabajo a 125 mil dólares canadienses y él lo rechazó. Porqué lo rechazó? Porque tenía otra oferta en Arabia Saudita por 250 mil dólares norteamericanos por año, libres de impuestos. ¿Vuestro gobierno puede pagar esta suma a su analista programador? La gente en Arabia Saudita, o en EE.UU. o Canadá a nivel privado lo podría hacer, pero los gobiernos quieren retener a la gente. Cuando uno está armando el plan de proyecto, uno que no puede ser demorado, cómo contemplarán la verdadera realidad de salarios en aumento en el sector privado? (sigue leyendo preguntas de encuesta) Esta es una pregunta que confirma lo que yo pensaba que era verdad. "Cómo comparo este problema con otros que han afectado a mi empresa u organismo en el pasado, como por ejemplo los cambios de moneda, la inflación, etc." De magnitud similar, el mismo tamaño de problema 28%. Más complejo 59%. Eso es lo que yo creo. Este es un problema significativamente diferente que la expansión de campo para la moneda. 30% dice que tendrá un impacto menor. No sé en qué se fundamentan, tal vez tengan razón. Lo que enfrentamos es básicamente esto: donde estamos hoy, nuestros programas no funcionan. Hace un rato, un periodista me acaba de preguntar "Esto no es un mito?". Y después de 6 años, seré honesto, no tengo tiempo para que me hagan este tipo de preguntas. No es un mito, se los puedo demostrar. De manera que en nuestra posición hoy, nuestros programas están destruidos. Entre hoy y mañana, cuando deben estar funcionado bien, existe un valle muy extenso, lleno de riesgos. De alguna manera tenemos que llegar de acá a allá, lo más rápido posible. ¿Cómo lo harán? Alguien me dijo durante el almuerzo "Peter, no es posible que esté exagerando la magnitud?". Posiblemente, pero yo no lo creo. Estoy dispuesto a reconocer que podría ser, pero no lo creo. Hay un hecho que es cierto: si Ud. empieza hoy, cuál es la principal desventaja? Va a terminar antes. Si empieza dentro de seis meses, la peor desventaja es que no habrá terminado en el plazo establecido y sus sistemas no van a funcionar. Si alguno de nosotros estuviera equivocado, yo preferiría ser el equivocado. Espero que uds. empiecen temprano y terminen temprano y puedan volver y decirme "todo los que nos dijo no sirvió para nada, mintió en todo lo que nos dijo, nosotros manejamos el problema y lo terminamos de antemano". Yo prefiero ser culpable de hacerlos terminar antes a hacerlos terminar un mes tarde. Hemos llegado al fin de un día muy largo. Uds. saben cuál es mi posición respecto al tema. Quisiera terminar con un concepto. Ese concepto es muy simple. No me crean. Vuelvan a sus oficinas y verifiquen. Y, si descubren que el problema es real y ya saben entonces que lo es, arréglenlo. La prensa me preguntaba hoy "cuál es la peor situación posible?" Porque la prensa se preocupa por cuáles son los escenarios catastróficos, quieren que les pinte la peor situación. Y aunque esté dispuesto a hacer esto hasta cierto punto, siempre les enfatizo que no es necesario tener la peor situación. Tenemos las habilidades, tenemos la gente, las herramientas, todo lo que necesitamos para resolverlo. Lo único que tenemos que hacer es decidir resolverlo. No me interesa si uds. eligen o no un proveedor, no me interesa si utilizan o no una herramienta. Lo único que me interesa es que lo resuelvan dentro de los plazos. Usen cualquiera de los proveedores, hay muchos muy honorables. Y si les preguntan cuál es su deseo más grande, es que uds. empiecen y terminen con esto. Los proveedores honorables, realmente no están concentrados en que usen los servicios de ellos sino en que sobrevivan el 90% de las empresas, como mínimo. Por favor, tienen las habilidades, tienen las personas y las herramientas para hacer lo que hay que hacer. Lo único que tienen que hacer es hacerlo. Alguna pregunta? (no hay preguntas. De Jager se ríe con la gente). No me sorprende que no haya preguntas! Hemos tenido un largo día, uds. se sienten magullados y apaleados. Es como si todo el día me hubiera pasado golpeándolos en la cabeza. Si no hay preguntas, entonces, les agradezco muchísimo haberme aguantado... (risas) Muchas Gracias de nuevo.

                VISTO el Decreto N° 998 del 30 de agosto de 1996, por el que se establecen las competencias de la SECRETARÍA DE LA FUNCIÓN PÚBLICA, dependiente de la JEFATURA DE GABINETE DE MINISTROS, en cuanto a los aspectos telemáticos (informática y sus comunicaciones asociadas) de la Administración Pública Nacional, y

                CONSIDERANDO:

                Que la Administración Pública Nacional enfrentará, al igual que el resto del mundo,  lo que se conoce como crisis del año 2000 o de cambio de milenio, cuya ocurrencia afectará a gran parte de los sistemas de información de los organismos que la componen.

                Que además de constituir un complejo problema de sistemas, puede afirmarse que el impacto del nuevo milenio sobre las aplicaciones que manejan fechas obligará a desarrollar un significativo proyecto de coordinación, además de constituir un fuerte desafío en el plano de su implantación.

                Que a diferencia de otros proyectos relacionados con las tecnologías de la información, cuyos tiempos admiten una administración más flexible, la inexorabilidad del problema y su universalidad, impiden toda invocación de demoras o de escasez de recursos, tanto humanos como materiales, como amparo para eximirse de los efectos que acarreará no llegar a tiempo a su solución.

                Que, por lo tanto, nos enfrentamos a un enorme e inevitable problema que, aunque de raíz técnica, tendrá impactos que habrán de proyectarse a todos los servicios informatizados que presta el Estado, cuya solución exigirá en cada organismo su planeamiento estratégico y la previsión de una cantidad significativa de recursos.

                Que, asimismo, la variable temporal se encuentra en relación inversa a la magnitud del problema, lo que pondrá a los organismos en la necesidad de tener que prever tal circunstancia en la forma de llevar adelante los procesos de contratación de todos los servicios que sean necesarios para hacer frente a la singular situación.

                Que a la par será necesario salvaguardar la transparencia de los procedimientos y decisiones, sin mengua de su eficacia y de los criterios de acierto que los animen.

                Que sin perjuicio de la actuación de los organismos afectados, sobre los cuales habrá de pesar la responsabilidad principal de las acciones, se hace necesario que la intervención de esta Secretaría en el ejercicio de su competencia cuente con el concurso de una unidad especial altamente calificada, de exclusiva dedicación a la asistencia y supervisión sobre las acciones que se adopten en pro de la solución de la citada problemática.

                Que dentro de las acciones asignadas a la competencia de la SECRETARIA DE LA FUNCION PUBLICA de la JEFATURA DE GABINETE DE MINISTROS, se encuentran las de proponer las medidas y dictar las normas que promueven el perfeccionamiento de la organización y el adecuado funcionamiento de la Administración Pública Nacional.

                 Que es competencia de la SECRETARIA DE LA FUNCION PUBLICA de la JEFATURA DE GABINETE DE MINISTROS, dictar el marco regulatorio para el establecimiento de las políticas sobre tecnologías referidas a informática, teleinformática, tecnologías multimedios, instalaciones y comunicaciones asociadas y otros medios y sistemas electrónicos, conforme lo establecido en el Anexo II del Decreto Nº 660/96.

                  Por ello,

LA SECRETARIA DE LA FUNCION PUBLICA

DE LA JEFATURA DE GABINETE DE MINISTROS

RESUELVE:

ARTÍCULO 1°.- Créase en el ámbito de esta Secretaría un área de proyecto de exclusiva dedicación, denominada "Unidad Ejecutora 2000", destinada al análisis, asistencia a los organismos, diseño de procedimientos, examen de propuestas y supervisión de las acciones a que de lugar la crisis en los sistemas provocada por el cambio de milenio.  Su vigencia temporal abarcará desde la fecha de su designación hasta el 30 de junio del año 2000.

ARTÍCULO 2°.- La "Unidad Ejecutora 2000" dependerá de la Dirección Nacional de Coordinación e Integración Tecnológica, sin que dicha dependencia altere la distribución y contenido de las competencias que conforme al Anexo II del Decreto N° 660/96 se definen y distribuyen entre las Direcciones Nacionales de Estandarización y Asistencia Técnica y de Coordinación e Integración Tecnológica, produciendo informes para el análisis y emisión de los dictámenes que correspondan.

ARTICULO 3°.- Serán funciones de la "Unidad Ejecutora 2000" brindar asistencia técnica a los organismos de la Administración Pública Nacional, centralizada y descentralizada, afectados por el problema generado por el cambio de milenio, elaborar procedimientos y supervisar su cumplimiento. Consecuentemente, todos los organismos de la Administración Pública Nacional, centralizada y descentralizada, deberán comunicar a esta Secretaría en el lapso de 30 días de la presente el inventario de los sistemas afectados por la crisis del cambio de milenio y las medidas que hayan previsto o prevean adoptar para su superación.

ARTICULO 4°.- La "Unidad Ejecutora 2000" tomará contacto con cada uno de los organismos en los que se registre el problema para examinar la naturaleza y magnitud de los aspectos en que se manifieste el efecto del cambio de milenio, y brindará el asesoramiento puntual que estime del caso, el cual no será vinculante.  No obstante ello deberá informar a la Dirección de la que depende acerca de cualquier apartamiento o desviación que se produzca en las acciones que el organismo asistido disponga cuando las mismas no sean consecuencia de las conclusiones del asesoramiento brindado. Asimismo, examinará todas las propuestas de contratación desde el punto de vista de su razonabilidad técnica y económica, e informará sobre las mismas a la Dirección Nacional de Coordinación e Integración Tecnológica y, por su intermedio, a la Dirección Nacional de Estandarización y Asistencia Técnica.

ARTICULO 5°.- La "Unidad Ejecutora 2000" se integrará en la forma que define el  Anexo  de la presente Resolución.  En el plazo de los próximos treinta días la Dirección Nacional de Coordinación e Integración Tecnológica propondrá  las designaciones correspondientes.

ARTICULO 6°.- Los gastos que demande la implantación del presente proyecto serán afectados a las partidas específicas del presupuesto correspondiente al ejercicio l998.

ARTICULO 7°.- Comuníquese, publíquese, dése a la Dirección Nacional del Registro Oficial y archívese.

RESOLUCION N°:  152/97

 

• 22 y 23 de setiembre de 1999,Curso sobre la problemática en las PYMES, de 6 hs., dirigido a Referentes de Cámaras Empresariales dado en la SFP. Se invitó a otras 60 Cámaras distintas a las ya invitadas en cursos anteriores.

 

• Setiembre de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 9 de setiembre de 1999, Con motivo de las notas enviadas se recibieron más de 230 emails notificando novedades sobre el posible problema del 9/9/99 en los sistemas informáticos de la APN. No se registró ningún caso con inconvenientes por causa de esta fecha. Ver informe.

 

• 3 de septiembre de 1999, II Reunión del Subgrupo de Telecomunicaciones del Grupo de Trabajo Ad-Hoc Año 2000 Mercosur, Chile y Bolivia, realizada en la ciudad de Montevideo.

 

• Agosto de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 18 al 19 de agosto de 1999, Curso sobre la problemática en las PYMES, de 6 hs., dirigido a Referentes de Cámaras Empresariales dado en la SFP. Se invitó a unas 60 Cámaras.

 

• 2 de agosto de 1999, Reunión entre participantes de la Lista de Discusión "a2000". Se informó sobre las acciones tomadas en la Administración Pública Nacional y se presentó algunos criterios para la realización de Planes de contingencia.

 

• Julio de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 28 de julio de 1999, Reunión Binacional con Bolivia, Subgrupo Pasos Fronterizos en Buenos Aires.

 

• 12 al 15 de julio de 1999, Curso sobre la problemática en las PYMES de 9 hs dirigido a referentes de Cámaras Empresariales dado en la SFP. Se invitó a unas 70 Cámaras.

 

• 6 y 7 de julio de 1999, V Reunión Grupo Binacional Argentina-Chile, en Buenos Aires.

 

• Julio de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 1 de julio de 1999, II Reunión Intersectorial Energía Eléctrica y Telecomunicaciones.

 

• Junio de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 30 de junio de 1999, Reunión con Responsables Año 2000 de Ministerios y Secretarías. Presentación sobre Lineamientos para el desarrollo de Planes de Contingencias.

 

• Junio de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 25 de junio de 1999, Reunión Binacional con la República Oriental del Uruguay, Subgrupo Pasos Fronterizos en Montevideo.

 

• 21 al 23 de junio de 1999, Reunión de Coordinadores de todo el mundo convocada por la Comisión de Informática de las Naciones Unidas en Nueva York.

 

• 16 y 17 de junio de 1999, Reunión del Global 2000 Coordinating Group, en Miami, donde se realizó una presentación sobre la situación en nuestro país.

 

• 15 de junio de 1999, I Reunión Intersectorial Energía Eléctrica y Telecomunicaciones.

 

• Mayo de 1999, Seguimiento y Control de los Planes de Acción y sus Hitos de Control de los Organismos de la APN

 

• 19 al 21 de mayo de 1999, II Reunión "Foro Y2K de América del Sur" en Washington DC

 

• 18 de mayo de 1999, Reunión Subgrupo Transporte Grupo Ad-Hoc Mercosur, Chile y Bolivia, en Santiago (Chile).

 

• 5 y 6 de mayo de 1999, IV Reunión Grupo Binacional Argentina-Chile, en Santiago, con los Subgrupos de Finanzas, Pasos Fronterizos, Transporte Aéreo, Transporte Marítimo y Puertos y vías navegables. 29 de Abril de 1999, Reunión Subgrupo Energía del "Foro Y2K de América del Sur", en Buenos Aires. 29 de Abril de 1999, II Reunión Subgrupo Energía Grupo Ad-Hoc Mercosur, Chile y Bolivia, en Buenos Aires

 

• 27 y 28 de Abril de 1999, Reunión de un FORO IBEROAMERICANO sobre "La responsabilidad del Estado frente a la problemática del año 2000" realizada en la ciudad de Buenos Aires en la sede de la SFP. Organizado por CLAD, CAIBI, SFP, INAP, AECI y FIIAP, con la participaron de 19 países.

 

• 15 de Abril de 1999, Reunión Subgrupo Energía del Grupo Binacional Argentina-Chile con participación de Empresas del Sector Privado realizada en la ciudad de Buenos Aires.

 

• 25 de Marzo de 1999, Reunión Subgrupo Pasos Fronterizos del grupo de trabajo Ad-Hoc Mercosur, Chile y Bolivia, realizada en la ciudad de Montevideo.

 

• 18 de Marzo de 1999, Como resultado de un trabajo conjunto con la Secretaría de la Función Pública, la Secretaría de Industria, Comercio y Minería ha publicado la Res. 173/99 que establece la obligación de identificar como "PREPARADO AÑO 2000" o "No Preparado año 2000" a determinados productos electrónicos.

 

• 10 y 11 de Marzo de 1999, II Reunión Ordinaria del Grupo Binacional Argentina-Chile, realizada en la ciudad de Buenos Aires, con la participación de los subgrupos: Comunicaciones, Finanzas, Transporte, Energía, Pasos Fronterizos.

 

• 9 de Marzo de 1999, Reunión Subgrupo Energía del Grupo Ad-Hoc Mercosur, Chile y Bolivia, realizada en la ciudad de Brasilia.

 

• 5 de Marzo de 1999, presentación sobre "Planes de Contingencia", realizada en el Ministerio de Cultura y Educación, Secretaría de Políticas Universitarias.

 

• 4 y 5 de Marzo de 1999, participación en la Primera reunión de trabajo del Foro Y2K de América del Sur, realizada en la ciudad de Lima, donde se realizó una presentación sobre la situación en nuestro país.

 

• 24 de Febrero de 1999, Reunión Subgrupo Telecomunicaciones del Grupo de trabajo Ad-Hoc Mercosur, Chile y Bolivia, realizada en la ciudad de Buenos Aires.

 

• 16 de Febrero de 1999, I Reunión Extraordinaria del Grupo Binacional Argentina-Chile, del subgrupo Pasos Fronterizos realizada en Sgo. de Chile.

 

• 27 y 28 de Enero de 1999, se participó en la reunión del Grupo Global 2000 en la ciudad de Londres, donde se realizó una presentación sobre la situación en nuestro país.

 

• 27 y 28 de Enero de 1999, I Reunión Extraordinaria del Grupo Binacional Argentina-Chile, realizada en Sgo. de Chile con la participación de los subgrupos: Comunicaciones, Finanzas, Transporte y Energía. 18 de Diciembre de 1998, I Reunión de la Comisión Ad-Hoc 2000 con Chile.

 

• 16 y 17 de Diciembre de 1998, se realizó en la ciudad de Buenos Aires, la II Reunión del Grupo Ad-Hoc 2000 Mercosur, Chile y Bolivia.

 

• 16 de Diciembre de 1998, se firmó el Memorándum de Entendimiento entre la República Argentina y la República de Chile, sobre cooperación para afrontar el problema informático del año 2000.

 

• 11 de Diciembre de 1998, se participó del Y2K Meeting, organizado por las Naciones Unidas y realizado en la ciudad de Nueva York.

 

• 11 de Diciembre de 1998, se participó en la reunión del grupo Binacional Argentina - Chile, donde se determinaron las pautas a seguir para la compatibilización año 2000 de las interfases entre ambos países.

 

• 11 de Diciembre de 1998, se realizó una presentación en la reunión Global 2000 que se desarrolló en la Ciudad de San Pablo, Brasil.

 

• 7 de Diciembre de 1998, se realizó una presentación sobre el tema de referencia en la ciudad de La Rioja invitados por el Gobierno de la Provincia.

 

• 27 de Noviembre de 1998, se realizó una presentación sobre el tema de referencia en la ciudad de Catamarca invitados por la Universidad Nacional de esa provincia.

 

• 25 de Noviembre de 1998, presentación sobre "La Universidad y la Problemática Año 2000", realizada en el Ministerio de Cultura y Educación, Secretaría de Políticas Universitarias.

 

• 20 de Noviembre de 1998, Seminario "Año 2000 - Concientización de la Problemática". Organizado por el Ministerio de Salud y Acción Social con la colaboración de la SFP, ante Representantes Provinciales, Cámaras de Fabricantes, Importadores y Distribuidores de equipos médicos y Obras Sociales.

 

• 17 de Noviembre de 1998, Presentación realizada conjuntamente entre la Secretaría PYME y la SFP ante la UNION INDUSTRIAL ARGENTINA.

 

• 1 de Octubre de 1998, Nota informativa del Sr. Presidente de la Nación a los señores gobernadores, sugiriendo la necesidad de la adopción de medidas en los ámbitos provinciales y municipales, análogas a las tomadas por la Nación.

 

• Octubre de 1998, Seguimiento y control de los Planes de Acción de los Organismos.

 

• 16 de Setiembre de 1998, Reunión convocada y presidida por el Sr. Jefe de Gabinete de Ministros con los responsables año 2000 de los Ministerios y Secretarías y de los organismos reguladores, para realizar un seguimiento del estado de situación y fijar las próximas acciones a seguir.

 

• Septiembre de 1998, Reuniones con los Organismos Reguladores para evaluar el estado de avance de sus acciones y fijar las pautas y requerimientos mínimos a solicitar a las empresas reguladas con respecto al contenido de sus planes de acción.

 

• 10 y 11 de septiembre de 1998 , 1ra Reunión del Grupo de Trabajo Ad Hoc sobre el Problema Informático del Año 2000 entre los países del Mercosur, Chile y Bolivia, según lo acordado por los presidentes de estos países en la reunión de Usuahia del 24 de julio de 1998. Cabe destacar que estuvieron presentes las delegaciones de Argentina, Brasil, Paraguay, Uruguay, Chile y Bolivia. Evento celebrado en Brasilia (República Federativa del Brasil).

 

• 2 de Septiembre de 1998, Notas SFP N° 869/98 a Ministerios y Secretarías fijando las pautas y requerimientos mínimos que deben contener los planes de acción para su aprobación.

 

• 22 de Julio de 1998, Decreto 856/98 modificatorio de la estructura de la Secretaría de la Función Pública de la Jefatura de Gabinete de Ministros, mediante el cual se crea la Subsecretaría de Tecnologías Informáticas. Los Organismos de la Administración Pública Nacional deberán elevar a la misma para su aprobación, los planes de acción para la adecuación de sus sistemas de información para ser compatibles año 2000, previo a cualquier contratación de bienes o servicios informáticos y sus comunicaciones asociadas.

 

• Julio 1998, Seguimiento de planes de acción de organismos. Soporte técnico en las tareas de adecuación año 2000. Seguimiento de grado de avance y de las pautas fijadas por los Entes Reguladores.

 

• Junio 1998, Envío de notas a Entes Reguladores para alertar sobre impacto en sistemas no informáticos.

 

• Mayo/Junio 1998, Reuniones con Responsables año 2000 de Ministerios y Secretarías de Presidencia de la Nación. Revisión de planes de acción para adecuación de sistemas al año 2000.

 

• Abril/Junio 1998, Soporte técnico a organismos en la realización de tareas de inventario y análisis de impacto preliminar.

 

• Marzo/Abril 1998, Reuniones con Responsables año 2000 de Ministerios y Secretarías de Presidencia de la Nación. Revisión estado de situación de cada organismo, evaluación de funciones críticas.

 

• 10 de Marzo de 1998, Reunión convocada y presidida por la Sra. Secretaria de la Función Pública con los responsables año 2000 designados, para la presentación de la metodología de funciones críticas.

 

• 5 de febrero de 1998, Notas SFP No. 106/98 y 107/98 a los Ministerios y Secretarías de Presidencia de la Nación Enero de 1998, comenzó sus funciones la Unidad Ejecutora 2000

 

• 12 de septiembre de 1997, Nota SFP Nº 811/97 a los Ministerios y Secretarías de Presidencia de la Nación

 

• 22 de agosto de 1997, Resolución SFP Nº 152/97 : "Creación de la Unidad Ejecutora 2000"

 

• 10 de julio de 1997, III Jornada sobre Nuevas Tecnologías para el Sector Público.

 

• 18 de junio de 1997, Nota SFP Nº 497/97 a los Ministerios y Secretarías de Presidencia de la Nación

28 de Diciembre 1998

1. Descripción del problema

2. Areas afectadas

3. Características distintivas del problema del año 2000:

3. Metodología

4. Aclaraciones

1. Marco de referencia para el análisis de riesgo

2. Clasificación de funciones por su criticidad

2.1. –Determinación de áreas de impacto

2.2. – Calificación de la gravedad de las consecuencias

2.3. – Identificación de funciones críticas

3. Conclusiones

1. Objetivo

2. Inventario de software estándar

3. Inventario de sistemas no informáticos o embebidos

4. Inventario de hardware y software de base

5. Inventario de sistemas en desarrollo

6. Inventario de funciones tercerizadas

7. Inventario de aplicaciones y análisis preliminar

7.1. División primaria de componentes - Particiones Lógicas

7.2. Identificación y depuración de componentes

a- Programas "activos"

b- Código compartido

c- Fuentes faltantes

d- Lenguaje de Control

7.3. Determinación del manejo de archivos y técnicas de adecuación

a- Archivos

b- Interfases externas

c- Archivos históricos.

8. Definición de estrategias de solución

9. Estimación de recursos y tiempos

1. Objetivo

2. Revisión de las Particiones Lógicas

3. Análisis e inspección de programas fuente

4. Definición de estándares y metodologías

4.1. Consideraciones especiales sobre tratamiento de fechas

4.2. Definición de Estándares para la corrección de los programas

4.3. Rutinas de Adecuación

4.4. Revisión final de las particiones lógicas y unidades de conversión

4.5. Manejo de versiones y metodología de cambios

5. Elaboración del Plan de conversión

5.1. Concurrencia de trabajos - Equipos de conversión

5.2. Definición de tareas y responsabilidades

5.3. Cronograma de conversión – Secuencia de tareas

5.4. Adecuaciones temporarias

5.5. Entrega de programas

5.6. Interacciones entre equipos de trabajo.

5.7. Control del proceso de conversión

5.8. Activación de los procedimientos de manejo de versiones y cambios

5.9. Planificación de Pruebas

5.10. Procedimientos de implementación en producción

5.11. Interfases externas

6. Instalación de Hardware y Software de base, compatible año 2000.

7. Planificación detallada de adecuación de los sistemas no informáticos

8. Elaboración de planes de contingencia

1. Establecimiento del entorno de trabajo

2. Traspaso de las Unidades de Conversión

3. Conversión

3.1. Corrección de Unidades de Conversión

3.2. Seguimiento de avance

4. Documentación de las correcciones

1. Introducción

2. El Plan de Pruebas

2.1. El Entorno y los Datos para las Pruebas

2.2. Características Particulares de las Pruebas de Año 2000

2.3. Prueba del Sistema en ambiente compatible año 2000

2.4. Añejamiento de los Datos

2.5. Pruebas mediante Proveedores Contratados

3. Metodología

3.1 Ambiente de Prueba

a- Lotes de Prueba

b- Pruebas Previas a la Conversión

c- Prueba de Eventos Críticos

3.2 Procedimientos Operativos

a- Pruebas Unitarias de Regresión

b- Pruebas Unitarias de Transición y Continuidad

c- Pruebas Integrales de Regresión

d- Pruebas Integrales de Transición y Continuidad

e- Prueba del Sistema

ANEXO I Sistemas Embebidos

ANEXO II Técnicas de Adecuación de Sistemas

ANEXO III Estimación de costos de adecuación año 2000

ANEXO IV Esquema de Control de Cambios

ANEXO V Técnicas de Bridging

ANEXO VI Planes de Contingencia

El problema se origina en la costumbre de referirnos al año con sólo los 2 últimos dígitos. Hasta el día de hoy, y en todos los ámbitos, todavía decimos que un automóvil es modelo 93, que en nuestra PC usamos un conocido sistema operativo en su versión 95 o 98, que nacimos en el 55 o que la fecha de hoy es 06/07/99. Esa costumbre se reflejó en la forma de registrar los datos de fecha en los archivos y, en consecuencia, la mayoría de los programas trabajan de modo que todo dato de año representado con 2 dígitos sea interpretado como del 1900, lo cual dejará de ser correcto a partir de los primeros datos que correspondan al 2000. No podemos decir que ninguna área de actividad humana esté exenta de este problema.

El problema del año 2000 afecta a la mayoría de las tecnologías informáticas y componentes electrónicos. Esto no se limita a las computadoras, software de base y aplicaciones, sino que también puede verse afectado equipamiento médico, sistemas de seguridad, sistemas de iluminación, sistemas de refrigeración, de control de procesos, sistemas de control ambiental, centrales telefónicas, sistemas de comunicaciones o cualquier otro equipamiento que tenga incorporado internamente circuitos integrados (chips) con lógicas sensitivas al tiempo.

Deben tenerse en cuenta no sólo los sistemas propios, mantenidos por cada organización, sino también los sistemas y tecnologías soportadas por proveedores externos, con los cuales se deberán determinar las acciones correctivas necesarias. Además, seguramente habrá intercambio de datos o "interfaces" con otras aplicaciones o sistemas, internos o con otras organizaciones, que deberán evaluarse con detenimiento para asegurar que sean compatibles con el año 2000 y no afecten a los sistemas internos. Con respecto al formato de los datos, se recomienda seguir las normas internacionales como, por ejemplo, la ISO 8601. También existe el problema de que no todos han tenido en cuenta que el año 2000 es Bisiesto por no hacer correctamente su cálculo.

Debido al corto tiempo para la llegada del próximo milenio, el enfoque descripto en este documento propone orientar y concentrar los esfuerzos iniciales de cada organismo en la evaluación del impacto del año 2000, sobre sus funciones críticas de operación y a la solución prioritaria de los mismos. Una vez que los problemas de mayor impacto hayan sido solucionados, se debería continuar con las correcciones necesarias para el resto de las funciones.

El impacto producido por el año 2000 puede afectar directamente la operación básica de los organismos, por lo que resulta necesario involucrar a:

Los máximos responsables de cada organismo en:

•La fijación de las metas •La Provisión de recursos •El Seguimiento general del proyecto

Los responsables de cada área funcional dentro del organismo en:

•La identificación de las diferentes funciones de su área y la evaluación del impacto que tendría su discontinuidad o problemas en la realización de las mismas, determinando así las funciones críticas •La Determinación, en conjunto con las áreas técnicas, de los recursos informáticos que soportan dichas funciones críticas

Los responsables informáticos para cada área en:

•La provisión de soporte técnico que les permita determinar aquellos recursos que soportan las funciones críticas •La identificación del impacto que el año 2000 podría tener sobre la operatoria de esos recursos

Las etapas para el análisis de Funciones Críticas son:

Etapa 1 Identificar las funciones críticas del organismo para concentrar las actividades del proyecto en la rectificación de los problemas del año 2000 que amenazarían la continuidad de dichas funciones.

Etapa 2 Identificar todos los recursos (computadoras, sistemas, proveedores, etc.) que son requeridos por el organismo para soportar las funciones identificadas en la etapa 1. Determinar las dificultades de compatibilización año 2000, de los recursos identificados en la etapa anterior. También para cada uno de los recursos se deberá determinar la naturaleza, tamaño, tiempo y costos estimados para la resolución del problema.

Un plan de contingencia es un conjunto de procedimientos alternativos a la operación normal, que le permitirá a su Organización seguir operando, aún cuando falle el sistema que soporta a alguna de sus funciones.

Ese plan tendrá las instrucciones y procedimientos para que la función pase a ser soportada por un sistema alternativo o para que sea cumplida sólo parcialmente. Hasta en algunos casos, dentro de este plan podría preverse dejar de cumplir la función afectada si ella puede postergarse o suspenderse por no ser crítica.

Las causas pueden ser un problema informático de su Organización, la falla en la entrega de información o insumo básico por parte de terceros o la falta de provisión de servicios básicos tales como energía eléctrica, gas, agua y telecomunicaciones.

La contingencia es en general atendida con alguna degradación en el nivel de servicio prestado y por un período limitado.

El hecho de que su Organización tenga un plan de contingencia no implica que se trabaje inadecuadamente. Por el contrario indica que su Organización es previsora y que está cubriendo las eventualidades tanto internas como externas, y una de ellas puede ser el problema informático del año 2000.

La preparación de un plan de contingencia relacionado con la problemática del año 2000, constituye en todos los casos una inversión adecuada ya que gran parte o la totalidad del mismo, así como la experiencia adquirida en su elaboración, serán aplicables a otros escenarios de contingencias.

La orientación principal de un plan de contingencia es la continuidad de operaciones de la Organización, no sólo de sus sistemas de información.

La siguiente guía le orienta cómo elaborar un plan de contingencia. El mismo consta de las etapas de Evaluación, Planificación, Pruebas, Ejecución y Recuperación. Las primeras tres dentro de la fase de prevención y las últimas dentro de la fase de reacción ante la falla.

Los Planes de Acción deben reflejar claramente las acciones que está llevando a cabo el Organismo para asegurar el cumplimiento de sus funciones críticas más allá del año 2000.

Las interfases entre distintos organismos tanto del ámbito público cómo privado deben considerarse detalladamente para asegurar su operatoria. Es por tanto necesario que en el plan de acción, estén claramente determinadas las interfases internas y externas con otros sistemas y las acciones de coordinación que al respecto se están llevando adelante.

Las funciones críticas deben tener un plan de contingencia apropiado, que permita asegurar su operatoria ante eventuales desvíos en los planes en curso o ante imprevistos no considerados.

A fin de facilitar la confección de planes de acción completos proveemos una presentación sobre la metodología a seguir, al final de la misma se encuentran pautas para su elaboración.

Consideraciones a tener en cuenta al estimar costos de adecuación

La prensa especializada, publicaciones en Internet, conferencias y prácticamente cualquier medio o evento que se refiera al tema del año 2000 y en particular sobre sus costos, han difundido estimaciones del mismo en frases que, si bien difieren en los valores de costo, poseen una estructura similar a la que sigue:

"A partir de las experiencias actuales de conversión se ha podido determinar que el costo de reparación varia entre U$S 1,10 y U$S 1,80 por línea de código COBOL, siendo aún mayor para programas escritos en ASSEMBLER".

Expresiones como esta, antes de ser utilizadas o dadas por ciertas, requieren un cuidadoso entendimiento y análisis de todos los aspectos que están involucrados en la determinación de los costos mencionados. El objetivo de este corto artículo es justamente intentar clarificar la visión de los mismos. El primer punto que requiere aclaración es la generalizada utilización de la cantidad de líneas de código para estimar los costos de conversión.

•La cantidad de líneas de código es simplemente una variable que ha demostrado estar relacionada, en el promedio de los organismos, con el esfuerzo requerido para efectuar la conversión, a mayor cantidad de líneas de código existe una mayor cantidad de líneas a revisar, alta probabilidad de encontrar líneas que deban ser corregidas, una cantidad importante de archivos y lenguaje de control como así también, mayor volumen de pruebas a realizar. •Si bien la cantidad de líneas de código y el lenguaje en que están escritas son variables que entran en juego, existen muchas otras que están relacionadas con el esfuerzo y por ende influyen sobre el costo para la adecuación del año 2000. •Una de las variables más importantes es la técnica que se siga para la conversión es decir, si es necesario expandir los datos y modificar los programas o pueden utilizar técnicas de "ventanas de fechas" que permiten mantener inalterados los datos requiriendo sólo la modificación de los programas. Este factor modifica de tal manera la complejidad y el esfuerzo requerido que varios consultores recomiendan que, de utilizar "ventanas de fecha" para estimar los costos totales de adecuación se considere sólo entre el 40 y el 60 por ciento del total de líneas de código. •Por otra parte las líneas de código que afectan el esfuerzo de conversión no son todas las que, en muchos casos, reposan en las bibliotecas de programas fuente, sino sólo aquellas que corresponden a programas que realmente se ejecutan. •Las que son reusadas en numerosos programas (tales como los "copys", rutinas insertas en los programas, etc.) deberían ser contadas una sola vez.

El segundo punto que está incluido en frases como las que encabezan este artículo es el del costo por línea de código. El valor que se menciona en casi todas las estimaciones es el costo total que la empresa u organismo debe considerar que tendrá todo el proceso de adecuación. Vale la pena recalcar dos palabras: COSTO TOTAL y analizar que elementos contribuyen a él. Para hacer esto es necesario tener en cuenta las distintas etapas que se requiere seguir en el proceso de adecuación, a grandes rasgos son:

1. Tareas de Inventario

•Identificación del Hardware y Software de Base que no es compatible y su solución: Esta es una tarea que debe ser encarada por personal del organismo y requiere consultas e interacción con los proveedores del mismo y su eventual reemplazo. •Inventario de programas, archivos, lenguaje de control. En esta tarea, si bien las herramientas o los servicios de los proveedores externos, pueden ser de utilidad, el principal peso recae sobre el personal del organismo.

2. Tareas de Análisis de Impacto

•Identificación de los campos de fechas en los archivos y su rango de validez, con el fin de determinar la posible utilización de la técnica de ventana o codificación. Esta es una tarea en la que prácticamente la totalidad del esfuerzo debe ser realizado por los analistas o usuarios del sistema ya que son los que están en condiciones de realizarla más eficientemente. •Definición de patrones de fecha y determinación de su ubicación en los programas Esta es una tarea en la que, de existir un proveedor externo, debe trabajar en estrecho contacto con el personal del organismo; los analistas del organismo identifican los patrones iniciales de fecha, el proveedor utiliza las herramientas para identificar y ubicar los mismos y su propagación (campos relacionados con los mismos que también contienen fechas) y requiere nuevamente de una cuidadosa revisión de los analistas del organismo para determinar efectivamente cuáles deben ser incluidas en el proceso de corrección y cuáles no. Tan importante es la participación del personal del organismo en esta tarea que la experiencia demuestra que el ritmo de avance en esta etapa, generalmente conocida cómo análisis de impacto, está dado por la velocidad con la que se realizan estas revisiones, ya que las herramientas entregan en poco tiempo, gran cantidad de material que debe luego ser analizado

3. Realización de las correcciones, documentación de las mismas y pruebas unitarias

Esta si, es una tarea que, una vez identificados los puntos de corrección, puede ser encomendada a proveedores externos, siendo de cualquier manera necesaria y conveniente la participación de analistas del organismo en la definición de las rutinas a utilizar para manejo de ventana y operaciones relacionadas con fechas a fin de asegurar su adecuación al organismo y para conservar el conocimiento sobre las aplicaciones que permita su posterior mantenimiento. De la misma forma es necesario que se realice una revisión de la documentación provista por el proveedor.

4. Pruebas de Aplicación y de Sistemas

En esta tarea, sólo los analistas de la instalación están en condiciones de definir los casos de prueba necesarios, la preparación del entorno y la verificación de los resultados, ya sea que las pruebas en sí las realice personal del organismo o del proveedor. La tarea que necesariamente debe realizar el proveedor, como parte de la garantía de su trabajo es la de efectuar las correcciones necesarias ante fallas que se presenten en esta etapa.

5. Implementación

Esta es fundamentalmente una tarea a realizar por personal del organismo. Todas las estimaciones sobre los esfuerzos relacionados con la concreción de estas tareas, incluyendo el Gartner Group, indican que no menos del 50 al 60% del esfuerzo total, se destina a la Realización de las pruebas (Item 4). Por otra parte se estima que el gerenciamiento del proyecto, tarea que no puede ser delegada por el organismo, incrementa en un 15 % el costo (esto incluye también el gerenciamiento propio del proveedor). También queda claro que en el restante 40 ó 50% del esfuerzo total, es sumamente importante la contribución del personal del organismo (la adecuación es siempre una tarea conjunta).

Hay que tener en cuenta que, de los costos totales por línea de código que se difunden, cuando se consideran los asociados con el proveedor externo, los mismos deberían encontrarse entre el 20 y el 30 % de los costos totales. Esta variación depende del grado de participación del mismo en el proceso. Estos valores coinciden, aproximadamente, con los encontrados en empresas que proveen servicios de adecuación en Buenos Aires. La mayoría cotiza por debajo de $0,50 por línea de código analizada y corregida. El resto del costo, debiera ser contemplado sobre los recursos propios del organismo que resultan indispensables en todo este proceso.

Rango de validez de los Sistemas

Todo sistema informático tiene en relación con sus datos un rango de validez asociado, tanto para la representación como para las operaciones que realiza con los mismos.

Dentro del rango de validez, un sistema informático debe cumplir dos condiciones:

•que los datos con los que trabaja sean unívocos •que las operaciones que realiza con los datos y los resultados sean válidas

Todo dato que un sistema almacene o intercambie con otro sistema debe estar en un formato tal que sea interpretado en forma unívoca.

Requerimientos para productos que trabajen con fechas

1. El producto deberá tener definido explícitamente un rango de fechas en relación con un calendario, también explícito, en el que cumpla plenamente su funcionalidad. En el rango de fechas definido, deberá manipular y representar en forma unívoca las fechas, en relación con el calendario especificado. Todas las operaciones que realice con las mismas y sus resultados, deberán ser correctas y conservar la misma relación unívoca.

2. Todo almacenamiento o interfase que incluya fechas deberá especificar en los mismos la centuria en forma explícita o a través de algoritmos o reglas de inferencia que no presenten ambigüedad.

Se define como Año 2000 compatible, todo componente que cumpla con los "Requerimientos para productos que trabajen con fechas" para el calendario Gregoriano y con los siguientes rangos mínimos de validez: Hardware y Firmware desde 1/1/1980 hasta 31/12/2030Sistemas Operativos desde 1/1/1980 hasta 31/12/2030Software de base y Sistemas de desarrollo desde 1/1/0001 hasta 31/12/2999Aplicativos El rango a establecer en estos casos, deberá ser acorde con el rango de fechas necesario para el correcto cumplimiento de todas las funciones que el sistema de información deberá soportar.

Para llevar a buen término cualquier proyecto de compatibilidad año 2000, el organismo que se lo proponga, ya sea con recursos propios o mediante servicios provistos por terceros, debe forzosamente involucrarse a pleno en una serie de tareas que no admiten ningún tipo de delegación. Estas tareas pueden agruparse bajo tres grandes líneas:

•Gerenciamiento general del proyecto. •Control de avance y de la calidad final de sus resultados. •Provisión adecuada y oportuna de toda la información, propia del organismo, requerida para la adecuación.

A fin de explicar más claramente su naturaleza, es necesario aclarar brevemente en qué consiste un proyecto de adecuación de sistemas informáticos para el año 2000 y relacionar las tareas con cada una de sus etapas.

Para adecuar un sistema en el que los archivos contienen el año de las fechas almacenado en dos dígitos (Por ej. 51, 97, 98) por lo cual los programas que trabajan con dichos archivos ordenan las fechas y realizan las operaciones considerando esos dos dígitos (lo que en el año 2000 llevará a errores tales como que el año 1999 será posterior al 2000 ya que 99 es mayor que 00), existen principalmente tres técnicas posibles:

1. Técnica de Ventana (Windowing): esta técnica es aplicable cuando se conoce que el rango de fechas que contiene el archivo está dentro de un intervalo menor que 100 años (Por ejemplo se sabe que no es válido que en el campo de fechas del archivo exista un año anterior a 1930). Esta circunstancia permite continuar usando el campo del archivo en dos dígitos y lo único que resulta necesario es introducir modificaciones a los programas para que si el año que encuentra en el archivo es inferior a 30, supongamos 25, lo tome como 2025 y si es superior, por ejemplo 51, lo trabaje como 1951, esto resuelve la indeterminación y permite que los ordenamientos y el resto de las operaciones con fechas resulten correctas. Cuando tiene que grabar nuevamente las fechas en un archivo, el programa almacena únicamente los dos últimos dígitos.

Esta técnica, si bien tiene el problema de que dejará de ser válida cuando en el futuro se incorporen fechas al archivo que correspondan al año 2030 o superiores (lo que debería suceder alrededor del año 2030), tiene la enorme ventaja de que permite utilizar los archivos tal como están sin tener que modificarlos para ampliar la longitud de los campos de fecha para que contengan el año en cuatro dígitos. Además permite la prueba y puesta en producción de los programas en forma unitaria.

2. Técnica de expansión: esta técnica consiste en ampliar los campos de fecha de los archivos para que contengan cuatro posiciones para el año y por ende requiere también la modificación de todos los programas que operen con ese archivo para que trabajen con la nueva longitud de los campos.

Esta técnica, si bien a priori parecería la solución más conveniente ya que no tiene limitaciones posteriores, tiene en su contra la gran complejidad que acarrea, ya que además de requerir la modificación de los archivos y de los programas, no permite la puesta en producción de ningún programa que trabaje con ese archivo hasta que todos los que lo utilizan sean modificados. Las pruebas requieren ser realizadas sobre el conjunto de dichos programas.

3. Técnica de codificación: esta técnica consiste en codificar los campos de fecha de los archivos para que en las dos posiciones del año o en la de los meses, o en algún otro campo que estuviera disponible del archivo se coloque un código que identifique la centuria.

Por ejemplo codificar las fechas correspondientes a meses o años del año 2000 o superiores con los meses 21 para enero, 22 para febrero, etc. o A0 para el año 2000, A1 para el 2001 y así sucesivamente.

Esta técnica, es utilizada en forma similar a la de ventana y en algunos casos se complementa con la misma para obtener el mismo tipo de resultado, identificar unívocamente una fecha aunque el año esté en dos posiciones. Tiene la ventaja de que las fechas anteriores al año 2000 se mantienen tal como están archivadas y sólo se requiere la modificación de las fechas posteriores. Por lo demás tiene las mismas ventajas que la técnica de ventana.

------------------------------------------------------------------------

El tema del año 2000 no sólo afecta a los sistemas informáticos, software, mainframes y computadoras personales sino a todo dispositivo electrónico que tenga lógica sensible a fechas.

La variedad de estos dispositivos que pueden verse afectados es realmente extensa. Por lo tanto, los líderes y responsables de los Proyectos año 2000 deberán en cada caso analizar cuidadosamente los posibles puntos de fallas, y gestionar el proceso de certificación e implementación de las actualizaciones con los proveedores correspondientes.

Para comprender mejor el problema es necesario entender básicamente como se maneja la fecha y hora en las computadoras personales. En general una computadora personal (PC) tiene dos relojes, uno interno, que llamaremos RTC (real-time clock) que está en el hardware, y uno externo, reloj del sistema (RSO), que es mantenido por el sistema operativo (SO). El RTC funciona aún cuando la PC esté apagada, mediante una batería interna. Cuando la PC se enciende, el RSO, se inicializa con el valor del RTC, a través de funciones del BIOS (Basic Input Output System). El BIOS, además de permitir el arranque de la PC, provee interfaces para la comunicación entre el sistema operativo y el hardware en forma de varios servicios (ej. obtener fecha/hora, inicializar fecha/ hora, etc.).

Los dos relojes funcionan en forma independiente. El RSO es un contador que se incrementa una cierta cantidad de veces por segundo. Con la fecha que obtuvo en la inicialización va calculando la fecha y hora. El RTC mantiene, en forma permanente, la información de la fecha (dd-mm-aa), en una memoria interna (CMOS RAM). El problema es que el siglo, que se almacena en otro lugar, no es incrementado automáticamente por el RTC cuando el valor del año pasa de 99 a 00. Por tanto el resultado es que 01/01/2000 parecerá ser 01/01/1900. El BIOS es el que debe actualizar el siglo, sin embargo en las versiones que no son compatibles con el año 2000 esto no sucede.

Además hay que tener en cuenta que el sistema operativo (DOS/Windows), incrementará correctamente la fecha que mantiene (RSO) si esta funcionando durante la transición de milenio, pero no necesariamente actualizará el siglo en el RTC. Mientras la máquina siga funcionando, la fecha del sistema operativo será correcta, pero si la computadora es reiniciada o encendida después del 01/01/2000, el RTC devolverá como fecha 01/01/00 al DOS. Este es un valor inválido, ya que DOS representa fechas posteriores al 01/01/80, y devolverá la fecha 04/01/80, que es un código de error.

El software que se utiliza en las PC lee la fecha de la computadora, de forma tal que, si esa fecha es incorrecta este error se extiende al mismo. Por tanto, es necesario verificar si su PC tiene una versión de BIOS que actualice automáticamente el siglo, de forma tal que cuando el RTC le devuelva como fecha 01/01/00 reconozca el cambio de siglo y el BIOS devuelva al SO la fecha 01/01/2000.

Para realizar esta prueba existen varios programas, (por ejemplo el de NSTL) algunos de libre distribución, que realizan la verificación. Es necesario leer en detalle las instrucciones para saber qué tipo de verificación están realizando.

La Superintendencia de Valores, considera que determinar el impacto fuera de cada una de las institución participantes en el mercado, es reconocer la magnitud del problema; ya que su desarrollo y crecimiento dependen en cierta medida del grado de seguridad que los inversionistas puedan percibir.

Si se conoce que alguna institución no puede garantizar la correcta ejecución de sus procesos internos, entonces, qué confianza puede generar con el público inversionista con respecto de sus movimientos y transacciones en este mercado. De aquí que podemos deducir que un factor crítico para el desarrollo y crecimiento del mercado de valores, es la confianza que se pueda brindar a los inversionistas por parte de la solidez de las instituciones participantes.

De esta forma, la Superintendencia de Valores ha elaborado un proyecto que pretende minimizar el riesgo de los problemas derivados del cambio de siglo. De esta manera, este problema deberá resultar transparente para el correcto desempeño de estas instituciones dentro del mercado de valores y los inversionistas que participen en él.

La estrategia de la Superintendencia de Valores se enfoca en dos factores principales:

1.Definición y seguimiento a la Normativa para orientar y regular la formulación y ejecución de planes de acción para enfrentar la problemática del año 2000.

2.Impulsar una campaña de Difusión dirigida a todas las instituciones participantes dentro del Mercado de Valores y demás instituciones interesadas.

Fecha de emisión

1/septiembre/1998

Fecha de vigencia

1/septiembre/1998

San Salvador, a las once horas del día primero de septiembre de mil novecientos noventa y ocho. El Superintendente de Valores, considerando:

I.Que el año dos mil implica riesgos que pueden afectar el normal funcionamiento de los sistemas de información de las entidades que intervienen en el mercado de valores, así como del resto de sectores de nuestra economía;

II.Que es muy alta la probabilidad de que los sistemas de información ocasionen problemas sistémicos, derivados del almacenamiento y procesamiento incorrecto de las fechas;

III.Que de conformidad con la Ley del Mercado de Valores, las entidades que intervienen en el mismo deben proporcionar información oportuna, completa y veraz;

IV.Que según el artículo 34 de la Ley del Mercado de Valores, los emisores deben informar los hechos esenciales y divulgarlos tan pronto como ocurran o se tome conocimiento de ellos;

V.Que es conveniente emitir el marco normativo que permita orientar y regular los planes de acción de las entidades que fiscaliza, inspecciona, vigila y fiscaliza esta Superintendencia, para la adecuación de los sistemas de información de cara al problema del año dos mil.

Por tanto, en uso de las facultades que le concede el literal b) del artículo veintidós de la Ley Orgánica de la Superintendencia de Valores y el Consejo Directivo de la Superintendencia de Valores, que en sesión No. CD-50/98 realizada el 20 de agosto de 1998, delego en el Superintendente de Valores la emisión de las resoluciones necesarias para enfrentar el problema del año dos mil, resuelve: Aprobar las siguientes " Normas para orientar y regular la formulación y ejecución de los planes de acción para enfrentar la problemática del Año 2000 " :

I.- El objeto de la presente resolución es asegurar la formulación y ejecución de los planes para adecuar los sistemas de información, el software y el equipo que apoyan el funcionamiento de las entidades fiscalizadas, vigiladas e inspeccionadas por la Superintendencia de Valores, respecto al problema del cambio de siglo.

II.- La presente resolución involucra a las entidades que conforman el mercado de valores, en lo que se refiere a sus sistemas de información, software de administración de base de datos, equipo computacional y las interrelaciones entre dichas entidades, para efectos de la transmisión y recepción electrónica de los datos e información que de alguna manera afecten al mercado.

III.- El Plan para Adecuar los Sistemas de Información constará de las siguientes etapas:

A.Análisis de la situación actual: En la cual se hace un reconocimiento minucioso de la situación actual, determinando la información, procesos, equipos, software, sistemas de información y otros aspectos donde pueda tener incidencia el próximo cambio de siglo.

Las actividades que incluye son:

1.- Elaborar un inventario detallado del hardware, software y sistemas de información desarrollados a la medida, y cualquier otro componente que contenga dispositivos electrónicos que almacenen fechas; y

2.- Análisis del equipo, software de terceros y sistemas de información desarrollados a la medida, a fin de identificar cuales están afectados por el cambio de siglo.

B.Planificación: Implica establecer la metodología y definir las acciones que aseguren la continuidad de los procesos críticos y la integridad y consistencia de la información procesada; en esta fase se definirán los recursos necesarios para lograr la correcta ejecución de lo planificado.

Las actividades que incluye son:

1.- Determinar el grado de afectación de las actividades a raíz del cambio de siglo;

2.- Establecer prioridades sobre la adecuación de los equipos, software y sistemas de información, de cara al año 2000;

3.- Establecer la estrategia de adecuación (abandono, conversión, nuevo desarrollo, migración o sustitución de equipos, software de terceros y sistemas de información);

4.- Elaborar el plan de conversión, determinando esfuerzos, medios y recursos; y

5.- Asociar a cada plan de conversión su correspondiente plan de pruebas, el cual deberá ejecutarse después de realizar los cambios para determinar el correcto funcionamiento del hardware, software y sistemas de información.

C.Implementación:En la cual se ejecutará lo planeado según las prioridades, estrategias, plazos y recursos asignados. Implica la aplicación de pruebas que permitan verificar el correcto funcionamiento de los cambios realizados dentro de la entidad y a nivel de mercado.

Las actividades que incluye son:

1.- Ejecutar las acciones de forma progresiva para el desarrollo de los cambios, de manera ordenada y de acuerdo a las prioridades y estrategias definidas;

2.- Realizar las pruebas incluídas en el plan respectivo; y

3.- Certificar todo el hardware, software y sistemas de información de la entidad.

D.Período de prueba: Debe llevarse a cabo después de realizar las adecuaciones y con el fin de verificar:

1.Que dichas adecuaciones no afectan ni modifican la operatividad de los procesos críticos de la entidad; y

2.Que los cambios y actualizaciones permitan adecuar el hardware, software y sistemas de información, de manera que se elimine o minimice el riesgo implícito en el próximo cambio de siglo.

E.Plan de contingencias: Incluye las medidas emergentes que se adoptarán en caso de que surja algún inconveniente durante el proceso de transición, derivados de la puesta en marcha del hardware, software y sistemas de información.

IV.- El Departamento de Informática de esta Superintendencia, proporcionarán las pautas, formatos y especificaciones técnicas que permitan la adecuación eficiente de las interrelaciones electrónicas de intercambio de información.

V.- Sin perjuicio de lo establecido en el Romano IV de la presente resolución, es responsabilidad de cada una de las entidades fiscalizadas por esta Superintendencia, ejecutar las acciones que conduzcan al efectivo cumplimiento del objeto señalado en el Romano I, de las presentes normas.

Los Directores y el Gerente General de cada entidad serán responsables de la ejecución de las acciones tendientes a cumplir con los objetivos señalados en la presente resolución, de la estricta supervisión y cumplimiento de los plazos establecidos; así como, del contenido de la información que se difunda al mercado y de la remitida a esta Superintendencia.

VI.- Los emisores de valores inscritos en el Registro Público Bursátil de esta Superintendencia, deberán informar al mercado, en calidad de hecho esencial y a más tardar el 31 de octubre de mil novecientos noventa y ocho, el plan de acción que seguirán para enfrentar la problemática del año 2000.

VII.- Las entidades que conforman el mercado de valores deberán informar a esta Superintendencia sobre los avances logrados al término de cada actividad, de conformidad a los formatos y plazos siguientes:

Los formatos señalados en el cuadro anterior serán enviados en medios magnéticos por esta Superintendencia; no obstante, las entidades sujetas a la presente resolución deberán remitir de manera impresa la información solicitada.

VIII.- La Superintendencia de Valores determinará las medidas y sanciones a tomar en caso de incumplimiento de la presente resolución.

IX.- La presente resolución entrará en vigencia el primero de septiembre de mil novecientos noventa y ocho.

El advenimiento del año 2000, como es sabido, acarreará múltiples problemas a todos los sistemas respecto de los cuales no se hayan emprendido, con la anticipación debida, las medidas correctivas apropiadas para, por lo menos, neutralizar sus negativos efectos.

El problema es serio y de gran magnitud, puesto que interfiere en todas las aplicaciones informáticas, así como en muchos dispositivos electrónicos (que no son computadoras) que utilicen lógica de fechas.

El problema del año 2000 no sólo interesa al mercado bursátil en El Salvador; todas las organizaciones, de cualquier nivel y naturaleza jurídica también puede ver afectado su funcionamiento por idéntica causa, y tendrán que encarar con la mayor urgencia su preparación.

El efecto 2000 está repercutiendo en entidades de todos los sectores en todo el mundo debido a la incapacidad de muchos Sistemas de Información de efectuar cálculos correctos con fecha posterior al 31 de diciembre de 1999 causado por el uso de dos dígitos únicamente para indicar el año. Esto obliga a que cada vez más empresas vayan tomando más conciencia de las consecuencias de este problema y asignen más recursos para minimizar el riesgo de quedarse un día sin poder operar normalmente.

En este sentido la Superintendencia de Valores, cuya misión es velar por los intereses del público inversionista, viene desarrollando el "PROYECTO PARA LA FORMULACION Y EJECUCION DE PLANES DE ACCION PARA ENFRENTAR LA PROBLEMATICA DEL AÑO 2000", que tiene por objetivo el asegurar la formulación y ejecución de los planes de acción para la adecuación de los Sistemas de Información, Software, incluyendo equipo que los soporta, que apoyan el funcionamiento de las operaciones de las entidades fiscalizadas, vigiladas e inspeccionadas por la Superintendencia de Valores, respecto al problema de cambio de siglo. Como parte de este proyecto se ha elaborado una campaña de difusión y orientación que permita a los participantes del mercado y cualquier otra empresa, desarrollar sus propios proyectos para el año 2000.

El origen del problema proviene de utilizar solamente los dos últimos dígitos del año en el almacenamiento y procesamiento de fechas. Esta era una práctica común de programadores, fabricantes de computadoras y otros equipos, que buscaban ahorrar espacio de almacenamiento, debido a los altos costos del mismo. Pero que implícitamente suponía que los sistemas no continuarían operativos para el año 2000, al no soportar el cambio de milenio en la lógica de los mismos.

Al utilizar sólo dos dígitos, el año 2000 se procesará como '00', teniendo consecuencias inesperadas y provocando comportamientos no previstos. Es el caso de cálculo de edades, años bisiestos, ordenamiento por fechas, generación de claves únicas, comparación por fechas, cálculos de intereses, fechas de vencimiento de títulos, etc.

El grado de impacto del año 2000 también dependerá de la naturaleza de la información almacenada o procesada, de la función soportada por el recurso (computadoras, sistemas, proveedores, interfaces, etc.) que falle y de la naturaleza de la falla.

Muchas organizaciones tienen sistemas que para sus cálculos actuales utilizan fechas en el futuro: proyecciones, tendencias, presupuestos, vencimientos, cálculos de intereses, etc. Para dichos organismos los problemas del año 2000 ya son un hecho y no ocurrirán sólo después de la medianoche del 31 de diciembre de 1999.

Supongamos que deseamos dar a cada trabajador una bonificación de ¢100.00 por cada año laborado en la empresa. Para el ejemplo consideraremos que un trabajador ingresó a la empresa el 1° de enero de 1985. Considerando que la fecha actual es 10 de enero del 2000, el cálculo sería el siguiente:

La Metodología propuesta considera las siguientes etapas:

A.La Etapa de Análisis de la Situación Actual: donde se hace un reconocimiento minucioso de la situación actual, determinando la información, procesos, equipos, software, sistemas de información y otros aspectos donde pueda tener incidencia el próximo cambio de siglo.

Las actividades que incluye son:

1.- Elaborar un inventario detallado del hardware, software y Sistemas de Información desarrollados a la medida, y cualquier otro componente que contenga dispositivos electrónicos que almacenen fechas;

2.- Efectuar un análisis de los equipos, software de terceros y sistemas de información desarrollados a la medida, a fin de determinar cuales están afectados por el cambio de siglo; y

3.- Elaborar un Plan de Contingencia en cada caso que los equipos, software de terceros y sistemas de Información no funcionen correctamente con la llegada del año 2000.

B.La Etapa de Planificación: involucra establecer la metodología, definir las acciones a tomar, que aseguren la continuidad de los procesos determinados como críticos, además de la integridad y consistencia de la información procesada, estableciendo los recursos necesarios para lograr la correcta ejecución de lo planificado.

Las actividades que incluye son:

1.- Determinar el grado de afectación de las actividades de la entidad, a raíz del cambio de siglo;

2.- Establecer prioridades sobre la adecuación de los equipos, software y Sistemas de Información, de cara al año 2000;

3.- Establecer la estrategia de adecuación (abandono, conversión, nuevo desarrollo, migración o sustitución de equipos, software de terceros y Sistemas de Información);

4.- Elaborar el Plan de conversión, determinando esfuerzos, medios y recursos;

5.- Asociar a cada plan de conversión su correspondiente Plan de Pruebas detallado, que incluya todas las áreas del negocio afectadas por el cambio de siglo, con la

finalidad de ejecutarlo luego de realizar los cambios para determinar el correcto funcionamiento del hardware, software y Sistemas de Información de la entidad.

C.La etapa de Implementación: que pone en marcha lo planeado, de acuerdo a las prioridades establecidas y las estrategias de realización identificadas, dentro de los plazos fijados y con los recursos asignados. Implica la realización de pruebas que permitan establecer el correcto funcionamiento de los cambios realizados dentro de la entidad y a nivel de mercado.

Las actividades que incluye son:

1.- Ejecutar las acciones de forma progresiva para el desarrollo de los cambios, ordenados de acuerdo a las prioridades y estrategias de adecuación definidas anteriormente;

2.- Realizar las pruebas previstas en el plan de Pruebas elaborado en la etapa anterior; y

3.- Certificar todo el hardware, software y Sistemas de Información de la entidad.

D.La Etapa de Prueba: debe llevarse a cabo una vez realizadas las adecuaciones en la etapa anterior, y deberán cubrir dos aspectos fundamentales:

1.- Que las adecuaciones realizadas no afecten ni modifican la operatividad diaria, de los procesos identificados como críticos; y

2.- Que los cambios y actualizaciones permitan efectivamente adecuar el hardware, software y sistemas de información, de forma tal que eliminen o minimicen el riesgo implícito en el próximo cambio de siglo.

E.El Plan de Contingencias: conlleva la realización de las acciones a ejecutarse en caso que surja algún inconveniente durante las transiciones, a consecuencia de la puesta en marcha del hardware, software y/o Sistemas de Información. 

•PENSAR QUE TENEMOS TIEMPO. •Creer que porque el problema es tecnológico, la solución es sólo tecnológica. •Esperar que alguien encuentre una solución rápida. •No involucrar a la alta dirección en este asunto. •Dejar que cada institución financiera resuelva su problema por sí sola. •Sobreestimar nuestra capacidad técnica. •Subestimar el problema. •Creer que los "proyectos" normales, actualmente en marcha solucionarán el problema. •Pensar que tenemos tecnología nueva, y por lo tanto no tendremos problemas. •Desestimar los planteamientos de otros, dado que nosotros no dependemos tanto de los sistemas como ellos. •Pensar que los proveedores de equipos y aplicaciones están hablando sobre esto para ganar más dinero.

Se deberá obtener la Certificación por parte de los proveedores tanto de hardware (equipos) como de software (Sistemas de Información y otros programas) sobre el correcto funcionamiento de sus productos.

Si embargo llegar a ella no es tan sencillo. Obtener esta Cerficicación implica tener una constancia por cada uno de los equipos, Sistemas de Información y software que se tienen instalados dentro de la empresa. Esto involucra:

- Realizar un inventario de qué es lo que se tiene

- Analizar qué de todo eso está afectado por el problema del año 2000

- Arreglar aquello que no está preparado.

Tomemos en cuenta que la Certificación la podemos obtener de la siguiente manera:

De los rubros antes mostrados, el tercero es el más complejo, ya que demanda revisar todos los programas que conforman nuestros sistemas de Información (empezando por los identificados como críticos para el negocio), a fín de encontrar cuales de ellos están afectados, luego corregirlos y finalmente la parte más importante, probar que los cambios realizados funcionan adecuadamente, es decir que arroja los mismos resultados que antes de la modificación.

Lo importante es que si inicia sus acciones ahora entonces evitará que su empresa pueda sufrir pérdidas económicas así como demandas legales, trayendo como consecuencia un deterioro de la imagen de su compañía.

A diferencia de otros proyectos, la fecha límite no puede ser prorrogada, la fecha es: 1° de enero del 2000, y esta es la realidad. En esta fecha los sistemas podrían caer en caos y dejar de funcionar hasta que sean reparados.

Finalmente, considerando la magnitud de un proyecto como éste, hay que subrayar la importancia de tomar acción inmediata sobre este tema, si es que aún no se ha iniciado, considerando la cantidad de recursos y costos que esta acciones pudieran involucrar.

Si su institución ha tomado cartas en el asunto, deberá analizarse si este proyecto tiene la prioridad adecuada; recuerde que la fecha límite no puede ser ampliada, podrían no estar dedicando los recursos necesarios, cuantifique sus pérdidas por cada día que sus actividades se vean interrumpidas y comprenderá la importancia de empezar ahora.

Recuerde, en el mundo hay tres tipos de gerentes o ejecutivos:

a.Las personas que hacen que las cosas sucedan; b.Aquellos que ven que las cosas suceden y c.Aquellos que se preguntan que fué lo que pasó.

Si usted está dentro del literal b) o c), será casi seguro que el impacto del año 2000, causará pérdidas económicas a su Institución, y casi seguro que pierda hasta su trabajo, por no haber actuado.

En las fechas en las que nos encontramos, comienzos de 1998, podemos asegurar que los responsables de sistemas de información conocen el problema que plantea el año 2000 (año en dos dígitos y bisiesto) e incluso han iniciado las tareas precisas para solventarlo.

El llamado "Efecto 2000" cuenta con varias posibles soluciones y en cada caso hay que determinar qué estrategia se va a seguir para que los sistemas funcionen correctamente llegado el año 2000.

Si tuviéramos que describir el "Proyecto Año 2000" brevemente, destacaríamos su gran componente manual.

Del estudio de la situación de partida en cada instalación se elige el modo de resolver el problema, para estas tareas existen herramientas que ayudan, pero no realizan el trabajo automáticamente. Tampoco las correcciones en los programas y/o datos y las pruebas son totalmente automatizables.

Así pues, dado que la puesta a punto de los sistemas para el año 2000 es un proceso que se basa en la intervención de personas, debemos tratar de contar con personal con experiencia o que conozca los sistemas y sobre todo calcular bien la duración de los trabajos. Para llegar a tiempo una sabia medida a tomar es tratar de terminar el proyecto unos cuantos meses antes del 2000 para hacer frente en este periodo a posibles eventualidades.

Todas las instalaciones y los edificios actuales suelen contar con equipamientos físicos que incorporan dispositivos electrónicos o microprocesadores que pueden verse afectados. Aquí se trata de examinar todos los dispositivos y proceder a la sustitución de los elementos afectados. Recordemos que ordenadores, relojes, ascensores, controladores de iluminación, sistemas telefónicos, contestadores, faxes, sistemas de seguridad, fotocopiadoras... son susceptibles a fallos llegado el año 2000.

Aún en el supuesto que hayamos corregido nuestros sistemas de información y sustituido los equipos físicos afectados debemos tener preparado un plan de contingencias ante fallos y estar preparados para afrontar posibles demandas por perjuicios.

En cualquier organización de tamaño medio o grande lo más probable es que se tenga que contar con apoyo externo para realizar el Proyecto Año 2000 en todas o algunas de sus fases. El factor tiempo tan importante en este proyecto (recordemos que pocos proyectos de desarrollo, mantenimiento o implantación acaban en la fecha prevista) puede hacer recomendable la utilización de servicios externos ya sean en forma de recursos humanos o de equipamientos físicos para conversiones y pruebas. Un servicio externo puede proporcionarnos experiencia en proyectos similares y conocimiento de herramientas disponibles que con la sola formación de nuestro personal difícilmente conseguiríamos conseguir a tiempo.

Las empresas que ofrecen 'soluciones 2000' en forma de consultoría, asistencia en programación, herramientas... van a experimentar una gran demanda en los próximos meses por lo que los contratos que firmemos deben especificar lo más posible los trabajos a realizar e incluir cláusulas que garanticen por ejemplo la estabilidad de los equipos, la experiencia en las plataformas y lenguajes de nuestra instalación así como garantías de que el trabajo contratado va a resolver el problema.

Hay que tener presente que no se debe confiar en exceso en los servicios externos y salvo en casos excepcionales no es recomendable contratar una externalización total del Proyecto Año 2000. La organización propietaria de los sistemas de información es quien mejor los conoce, es la responsable de su funcionamiento y quien responderá ante posibles fallos.

La envergadura del Proyecto 2000 (hay que revisar todos los Sistemas de Información, corregir y probar los afectados e implantar los sistemas corregidos) aconseja dividir el proyecto en fases y contar con una gestión del proyecto que garantice que los recursos serán bien utilizados y que se cumplan los plazos previstos. Es aconsejable que la Gestión del Proyecto Año 2000 se realice con recursos propios pero si la complejidad de la instalación obliga a contar con ayuda externa para la gestión del proyecto debemos recordar que los que responderemos ante los fallos seremos nosotros y que por muchas cláusulas de garantía o penalizaciones que incluyamos en los contratos no se puede asegurar que los sistemas funcionarán bien en el año 2000.

Hasta el momento hemos hablado de los equipos físicos, software empotrado y aplicaciones a medida de nuestras instalaciones. Vamos a dedicar en este apartado unas líneas para referirnos a los sistemas operativos, middleware, sistemas de gestión de bases de datos, paquetes de software y cualquier otro software suministrado externamente )Qué hay que hacer con este software? La respuesta es sencilla: hay que ponerse en contacto con nuestros suministradores para conocer si las versiones que tenemos en nuestra instalación van a ser corregidas caso de estar afectadas y en qué fechas podremos disponer del software para incorporarlo a nuestra instalación. Puede ocurrir que no en todos los casos el software de nuestra instalación vaya a ser conforme al Año 2000 y puede que el suministrador nos Aobligue@ a migrar a las últimas versiones de su software. Así pues, esta es otra pieza más a tener en cuenta en el Proyecto Año 2000.

Esta es una de las mayores dificultades que presenta el Proyecto Año 2000. No podemos >congelar= nuestra instalación mientras se procede a solucionar el problema del 2000. Los sistemas requieren al menos su mantenimiento correctivo habitual y aunque en la medida de lo posible se evitarán nuevos desarrollos, migraciones, etc... a veces no se podrá evitar la coincidencia temporal como puede ocurrir en el caso del Euro.

No hay una solución más idónea que otra y dependerá de la instalación concreta el abordar los dos proyectos separada o simultáneamente. Lo que es indudable es que hay sinergias: inventario detallado de aplicaciones, método o proceso de cambios y pruebas, herramientas, en definitiva, la experiencia adquirida en el Proyecto Año 2000 puede ser muy útil en el Proyecto Euro. En general en las Administraciones Públicas se abordará antes el Proyecto Año 2000 y en las entidades financieras el Proyecto Euro.

Sin embargo, en todos los casos será preciso establecer un plan de sustitución de los sistemas o aplicaciones ya corregidas y realizar los puentes necesarios para que los sistemas ya corregidos funcionen temporalmente con los no corregidos. El plan de sustitución de los sistemas ya corregidos se determinará en función de las relaciones entre nuestros sistemas, de las relaciones con los sistemas de información de otras organizaciones y de la disponibilidad del software conforme con el 2000 de suministradores externos.

El gran volumen de tareas a realizar, el coste y el limitado plazo de tiempo para realizarlas requiere un procedimiento específico de trabajo.

Como ya hemos indicado anteriormente es recomendable dividir el trabajo en fases y establecer una gestión muy eficaz del proyecto.

Si no se cuenta con un proceso y herramientas de gestión de configuración; control de cambios y de versiones, es posible que nos perdamos por el elevado número de programas y ficheros a modificar y el elevado número de personas de la organización o contratadas que van a intervenir, las relaciones entre elementos cambiados y no cambiados, el mantenimiento habitual, etc...

Puede ser necesario establecer un proceso de gestión y el aseguramiento de la calidad, a veces las pruebas no son suficientes para asegurar el funcionamiento correcto de los sistemas al llegar el año 2000.

- Inventario completo y detallado de los recursos software y hardware de la instalación

- Estimación de recursos, Estrategias y Plan de Trabajo con prioridades

- Realización de los cambios y las pruebas e implantación de los sistemas modificados

Para las aplicaciones será preciso conocer su localización, tamaño, elementos que la componen, lenguaje, interfaces con datos y con otras aplicaciones, estado de documentación, si están o no explotación, correspondencia de los objetos con las fuentes.

Al tiempo habrá que localizar todas las referencias o fechas en las preguntas y en los datos, esta tarea puede ser compleja y además de las herramientas será preciso contar con la ayuda de los responsables del desarrollo o mantenimiento de estas aplicaciones. Las herramientas más interesantes son aquellas que disponen de criterios de búsqueda o reglas estándar a las que se puedan incorporar nuestras propias reglas que podrán basarse en el nombre de los campos o de las variables o en el formato (tipo, longitud, máscara). También son útiles las herramientas que además de localizar las variables afectadas informan sobre su propagación en programas y rutinas.

La realización del inventario puede llevar bastante tiempo y puede producir resultados inesperados.

Por otra parte será preciso inventariar los recursos hardware y el software de suministradores externos.

Una vez realizado el inventario, mediante un proyecto piloto y extrapolando sus resultados o bien analizando todos nuestros sistemas exhaustivamente, estaremos en condiciones de calcular el impacto del problema en nuestra instalación con un margen de error razonable y proceder a la estimación de recursos físicos y humanos y experiencia requerida para adaptar nuestros sistemas.

También estaremos en condiciones de decidir qué técnica se va a utilizar en función del coste y la criticidad de las aplicaciones: expansión de datos, codificación de datos, ventanas... Las normas: cláusulas tipo, formatos de intercambio de información... Las herramientas a utilizar.

Por último estableceremos el plan de trabajo para la corrección e implantación con las tareas, el calendario de realización y la distribución de los recursos. Habrá que establecer prioridades y grupos de aplicaciones homogéneas atendiendo a su criticidad y a su relación con el resto de las aplicaciones o su funcionalidad. Es muy importante obtener una planificación detallada que sea la base para la gestión de nuestro proyecto tanto por la cantidad de elementos a corregir como por el gran número de personas que intervendrán en el proceso: personal directivo, usuarios, responsables de las aplicaciones, jefes de proyecto, personal de desarrollo o mantenimiento propio o externo, personal de explotación, técnicos de sistemas...

Dado el escaso tiempo del que disponemos para realizar los cambios, siempre que sea posible, la conversión deberá acometerse utilizando herramientas.

Habrá que realizar una elección previa de una o varias herramientas para lo que podremos contar con ayuda externa que posiblemente tendrá experiencia en la utilización de varias herramientas.

Hay herramientas con distintas funcionalidades: estimación, planificación, desarrollo, mantenimiento, gestión de proyectos, gestión de configuración, gestión de calidad..., algunas de ellas han sido adaptadas y sirven de ayuda a la realización del Proyecto Año 2000: Analizadores de código, conversores de programas y datos, simuladores para pruebas, etc...

Hay que advertir que la utilización de herramientas no es suficiente para dar solución al problema del 2000, no hay ninguna que automatice la totalidad del proceso, la mayor parte de las herramientas son para COBOL y MVS, aunque van apareciendo para otros lenguajes y sistemas operativos y van mejorando sus prestaciones continuamente. Las herramientas más completas son complejas y precisan de formación para su utilización. El entorno operativo de la herramienta debe ser considerado antes de tomar una decisión.

El esfuerzo de realización de pruebas es uno de los más importantes del proyecto, puede ser incluso mayor que el de corrección. Es fundamental contar con datos de prueba lo más completos posibles. Como en algunos casos es necesario modificar la fecha del sistema para realizar pruebas, siempre que sea posible se recomienda usar un sistema distinto para pruebas.

Las pruebas unitarias de integración pueden ser realizadas externamente. Las pruebas del sistema y de aceptación se realizarán preferentemente en la propia instalación. Las pruebas variarán según la técnica de conversión utilizada: expansión, ventanas, compresión.

El Consejo Superior de Informática en cumplimiento de su misión coordinadora de la informática de la Administración General del Estado ha llevado a cabo las siguientes acciones:

. Jornada de sensibilización e información: El Euro y el Año 2000 en los sistemas de información de las Administraciones Públicas. Se celebró el 15 de octubre de 1997 y se trataron entre otros los Aspectos organizativos y presupuestarios de ambos problemas, las Estrategias para la adaptación al 2000 y al EURO, las soluciones metodológicas y de herramientas. Además pudimos conocer la problemática en la Agencia Estatal de Administración Tributaria de la introducción de la moneda única y en la Gerencia Informática de la Seguridad Social de la adecuación de sus sistemas al 2000.

. Información y seguimiento permanente a través de las Comisiones Especializadas del Consejo: CIABSI (Comisión Interministerial de Adquisición de Bienes y Servicios Informáticos) y COAXI (Comisión Nacional para la Cooperación entre las Administraciones Públicas en el Campo de los Sistemas y Tecnologías de la Información) de las actividades e iniciativas y de los proyectos 2000 y EURO tanto en las Administraciones Públicas como en el sector privado, así como el seguimiento de productos y servicios disponibles en el mercado para ayudar en el proceso de adaptación.

. Establecimiento de sendas cláusulas tipo 2000 y EURO aplicables a los contratos firmados técnicamente por la CIABSI ya sean suministros o contratos de servicios.

. ASÍ 2000: "Adecuación de Sistemas de Información al 2000". Se trata de un método común que ayudará a resolver el problema del 2000. Estará disponibles en Enero de 1998.

. El Instituto Nacional de Administración Pública ha realizado durante 1997 y va a realizar en 1998 cursos sobre la adaptación al EURO y al 2000 de los sistemas de información de las Administraciones Públicas.

. A lo largo de 1998 se realizarán acciones de información, apoyo y difusión al proceso de adecuación al 2000 y de seguimiento del proceso en la Administración General del Estado.

Donald Rose, jefe del operativo internacional de Intel para evitar que los problemas informáticos del año 2000 afecten la producción de microchips, tiene la mira puesta en 500 proveedores críticos de materiales y de servicios básicos, como la electricidad y el teléfono.

Intel se está ocupando intensamente de suministrar ayuda en materia de capacitación, pruebas y auditoría a la otra mitad de los proveedores -muchos de ellos del exterior- con la esperanza de que lleguen a tiempo. Intel comenzó a comprar generadores de repuestos, a entrevistarse con proveedores alternativos y a realizar otros preparativos ante la posibilidad de que se produzcan desperfectos.

Por supuesto, Intel no es la única.

Después de meses de sopesar opciones, las empresas y los gobiernos están reconociendo que ciertas complicaciones son inevitables cuando las computadoras encuentren fechas posteriores a 1999, y que ahora ya les corren los últimos plazos para invertir en planes de emergencia.

No es un tema que a los directivos y sus líderes de proyecto les guste comentar los planes para imprevistos deben tener en cuenta no sólo los propios sistemas de los usuarios, sino todas las demás fuerzas externas que escapan a su control, tales como el agua, los teléfonos y la electricidad pública.

Así y todo, el operativo permite visualizar con qué grado de seriedad el mundo está tomando el desafío del milenio. El problema tiene su origen en la práctica usual durante décadas, de utilizar dos dígitos para representar el año en las fechas.

Las computadoras, el software y los aparatos electrónicos podrían funcionar mal si leen "00" como "1900", o si no reconocen eso como una fecha.

La mayor parte de la planificación ante posibles emergencias por el 2000 apunta a anticipar desperfectos locales similares a los que la sociedad suela padecer en caso de fallas de equipos, mal tiempo y terremotos.

Intel empezó a instalar generadores eléctricos adicionales en las plantas asiáticas y latinoamericanas que tienen redes eléctricas frágiles. Y sus compradores y técnicos estuvieron visitando empresas a las cuales Intel hoy no les compra, para ver si ellas podrían intervenir en caso de que algún proveedor fallara.

Hoy en día las empresas se ven obligadas a destinar recursos para tratar de solucionar este problema. Deberán pagar una buena parte de los 1.500 millones de dólares que costara en el país la reconversión de los sistemas informáticos.

El Banco Nación, Visa, Argencard, Metrogas, Supermercados Norte, Wal Mart e YPF son algunas de las compañías que iniciaron acciones millonarias para ponerse a resguardo ante esta crisis.

Una de cada diez empresas admitió que le quedarán temas pendientes por resolver cuando los relojes marquen el primer segundo del año 2000 y el inicio, quizá, de la crisis informática. Deben cerciorarse de que sus proveedores y hasta los proveedores de sus proveedores, reduzcan al máximo los riesgos que podrían producirse en toda la cadena comercial.

Es el caso del Banco Nación. La entidad oficial destinó 12 millones de dólares y puso a trabajar a 100 personas para analizar entre otros, el sistema de depósitos, plazos fijos y préstamos que unen a todas sus sucursales con el computador central.

Por su parte YPF inyectó 30 millones de dólares al Proyecto año 2000 -así lo llamaron-, cuya finalización está prevista para mediados del `99. Además de hacer un seguimiento, para conocer cómo enfrentan el problema 300 clientes, planea "visitar personalmente", a sus proveedores más importantes.

A pesar de todos los recaudos, "sería absurdo decir que tenemos el control total de nuestras operaciones, porque estamos ante un tema inédito", reconoce el ejecutivo.

Sólo en la renovación de aparatos informáticos, Wal Mart invirtió más de 1,5 millón de dólares. Pero ese presupuesto no contempla la revisión de los sistemas electrónicos, cajas registradoras y depósitos, que también encaró la compañía

Para Supermercados Norte, que destinó un millón de dólares en el cambio de equipos informáticos y consultoría, los proveedores más críticos son las PyMEs y las Microempresas.

En tanto, Metro Gas, que no revela el monto de la inversión, previó 15 "fallas posibles". Algunas de ellas van desde el aprovisionamiento hasta el transporte de gas al área metropolitana.

Máxima AFJP reconoce que aún "no pudimos avanzar todo lo posible", para asegurar que se acrediten los aportes de sus afiliados. "Encontramos ciertas reticencias para hacer pruebas con algunos organismos del Estado, como la DGI", señala Fabián Bernard, jefe de desarrollo.

Tanto en Visa como en Argencard dicen que sus clientes no tendrán "sorpresas desagradables". Ambas compañías admiten que el problema del año 2000 se convirtió en un tema de máxima prioridad por las implicancias en el futuro de sus negocios.

Las PyMes son las más rezagadas. Cuanto más pequeña es la empresa, mayores son los temas pendientes.

El problema es que si no analizan y resuelven los riesgos, van a tener que hacer fuertes inversiones en un momento de restricción crediticia.

Actualmente , hay unas 120 entidades en el sistema bancario argentino. "Los bancos líderes, unos 25, están bien preparados. Aunque unos 30 o 40 bancos más chicos corren riesgos", asegura Carlos Isacovich, de Hista, empresa dedicada al testeo de software para banco.

Los bancos no actualizados podrían ponen en riesgo todo el sistema, ya que todos están en red y la falla de una computadora en un banco podría repercutir en el otro. Por eso, cualquier persona que opere con alguna de las redes de cajeros automáticos, en el país ya son miles de personas que cobran sus sueldos a través de cajeros, podría verse afectado, a pesar de que el banco en el que tiene su cuenta no registre problemas.

"El dinero no va a desaparecer, sino que dejaría de estar disponible por tiempo indeterminado, lo que lleve arreglar el problema.

Según la secretaria de la pequeña y mediana empresa, el 73% del sector no tiene un plan. El problema informático afecta los sistemas de facturación, administración, control de stock y producción.

Esta importancia convierte a su atraso en una amenaza para la economía nacional.

"No son pocos los dueños de PyMes que creen que nada grave puede pasarle a su empresa. Algunos, inclusive, llegan a decir que si tienen problemas con las dos o tres computadoras que poseen las desenchufan y vuelven al viejo método manual con libreta y talonario. Por eso es imposible: todos sus registros están en las computadoras y en especial su sistema de facturación y stock"

Muchas PyMes son proveedoras directas de grandes empresas y el efecto 2000 podría afectarlas no sólo a nivel interno sino también dentro de su cadena comercial. "Las grandes industrias pedirán certificación de compatibilidad 2000 entre setiembre y noviembre de este año y pueden dejar de trabajar con aquellas compañías que no ofrezcan garantías".

Como una gran cantidad no tiene departamento de sistemas interno, la solución del año 2000 es un gasto extra.

"Ese es el principal obstáculo a la hora de pensar en hacer algo; nadie quiere gastar y encima, es un problema que todavía no perciben. Es casi imposible hacerle entender al dueño de una pequeña empresa que cuando lo perciba va a ser demasiado tarde".

Las áreas donde el impacto del año 2000 puede ser grave dentro de una PyMe, son las de facturación, control de stock, producción y administración. "El problema alcanza a los proveedores, clientes y al sector de recursos humanos, donde puede haber errores en el cálculo de salarios, vacaciones y aguinaldos".

Una vez que se establecen los cambios, hay que adecuar los sistemas, hacer las pruebas correspondientes y armar un plan de emergencia. Esto lleva entre 3 y 4 meses de trabajo.

Una de las tareas fundamentales en relación a este problema, es conocer la compatibilidad año 2000 de los equipos y sistemas instalados en la empresa, como también la situación de los proveedores de elementos críticos y clientes importantes.

A estos efectos es que proponemos dirigir las siguientes cartas:

 

• Carta dirigida a los fabricantes o proveedores, no especializados en tecnología de la información, para comprobar si los que abastecen de bienes y servicios críticos, continuarán operando normalmente como consecuencia de la llegada del año 2000.

 

• Carta dirigida a proveedores de bienes que incluyen tecnología de información con control de fechas, para requerirles la certificación de los respectivos productos instalados en la empresa.

 

• Carta dirigida a clientes importantes que representan una porción significativa del negocio, para conocer su situación con relación al problema del año 2000.

Edgardo Jury, director local de la consultora Gartner Group.

Según las proyecciones de la casa matriz de su consultora, el efecto 2000 producirá litigios por un billón de dólares (un millón de millones), en el mundo, un 30 por cinto más de su costo técnico.

El primer juicio por el efecto 2000 lo inició en Estados Unidos la cadena Produce Palace a la fabricante de máquinas registradoras TEC hace dos años. Las cajas no aceptaban cuota más allá de 1999.

Luego vinieron juicios a empresas proveedoras de programas y equipos de computación. En Argentina ya hay un juicio contra una tarjeta de crédito.

"La ley de defensa del consumidor ampara todo el que se haya visto perjudicado por este tema a demandar con derecho hasta tres meses después de descubrir el vicio oculto".

Después del 2000, además, llegarán los perjuicios a las empresas que no puedan cumplir sus operaciones. "Una empresa no va a poder alegar el caso fortuito. Si es demandada, por la ley de sociedades, el director responderá con su patrimonio solidaria e ilimitadamente, porque se pondrá en duda algo que la ley de sociedades denomina la calidad de buen hombre de negocios que hace todo lo posible por llevar adelante la empresa con debida diligencia.

Por eso, las empresas tienen que documentar todas las previsiones y pruebas que hicieron, para alegar que no hubo imprevisión".

Las grandes empresas ya incluyeron en sus contratos con proveedores pequeños un punto el que los hacen comerciantes responsables de cualquier incumplimiento."El contrato es la ley de las partes o sea que las pequeñas empresas asumen el riesgo en la venta. Lo que pasa es que tienen su poder de negociación disminuido y no se juntan", dice Andrea Sarra, profesora del postgrado en asesoría jurídica de empresas de la UBA.

La situación de las empresas pequeñas es preocupante en todo el mundo.

Estas empresas serán un blanco fácil no sólo por sus posibles fallas operativas, sino también por la falta de información legal que tienen sus dueños. Vulnerables para enfrentar juicios, son categorizadas como "negocios de alto riesgo".

En los Estado Unidos, las grandes corporaciones aprovechan esto para expandirse. El precio de las pequeñas empresas no preparadas desciende y esto facilita que sean absorbidas.

Las empresas públicas argentinas presentan este panorama:

* Telefónica: Suponen que en agosto tendrán todo listo. Desde 1997 la empresa trabaja en el "Proyecto Milenio". Ya se realizaron pruebas.

*Telecom: El 30 de junio terminarán las pruebas. Los últimos seis meses del año serán dedicados a monitorear y ajustar los cambios.

* Metrogas: El servicio a los usuarios está garantizado. Sólo podrían surgir problemas en la facturación y cobro a los grandes consumidores.

*Aguas Argentinas: Garantiza a los usuarios que no se verán afectados. Aún están trabajando en las áreas de administración y financiera.

* Movicom: El problema del año 2000 podría afectar a las áreas de facturación y cobranza pero no al suministro del servicio. Las pruebas terminarán en junio de 1999.

*Miniphone: Los sistemas más importantes ya están actualizados.

*Metrovías: (subtes) Aseguran que están preparados. De todos modos, realizarán una prueba final hacia fines de mayo. Las principales áreas afectadas podrían ser: señalización, escaleras mecánicas y ascensores.

* Metropolitano: (trenes) Dicen que no tendrán grandes problemas porque muchas de las funciones se realizan manualmente. De todos modos, a mediados de junio realizarán una prueba para garantizar que no haya problemas en la venta de pasajes y las tareas administrativas.

* Aerolíneas Argentinas: Las situaciones más criticas se pueden producir en loa aeropuertos. De no actualizarse, lo peor que puede ocurrir es que un avión no pueda despegar. La empresa ya actualizó el 60 por ciento de sus sistemas.

*Transporte automotor: La asociación Argentina de empresas del Transporte Automotor (AETA) no cree que haya problemas en la venta de pasajes.

1) ¿Cuales fueron los cambios más notables, en las tendencias del Mercado durante 1997?.

El año 2000 comenzó a influenciar fuertemente en las decisiones de los Gerentes de Sistemas aunque paradójicamente son pocas las empresas que ya están trabajando en el tema o tiene un plan de acción concreto y definido.

2) ¿ Cómo será el escenario en el que se desarrollará el negocio de su empresa durante 1998?

Hemos desarrollado una estrategia que apunta a resolver la problemática del año 2000, acompañada por herramientas y metodología que le permitan a las empresas continuar siendo competitivas u obtener fuertes ventajas en los próximos años y después del 2000.

3) ¿Cómo afectará el impacto tanto a clientes como a proveedores dentro de la industria de la información?

Seguramente el problema del año 2000. Aun no se han tomado total conciencia del tema, pero ya se está vislumbrando que empieza a peligrar la existencia de algunas empresas. También desde el punto de vista de los proveedores, los costos para adoptar sus soluciones pueden poner en riesgo su continuidad. Otro elemento importante es que ya empieza a notarse una alarmante escasez de recursos humanos lo que seguramente agravará este panorama en 1998.

La industria que más ha avanzado en la resolución de este problema es la bancaria, el propio Banco Central se encuentra presionando fuertemente a las instituciones para que tengan resuelto el problema para fin de año.

1. ¿Cuáles fueron los cambios más notables en las tendencias del Mercado durante 1997?

Los cambios más notables en las tendencias del Mercado durante 1997 con respecto al software de aplicación, escenario en el cual desarrollamos nuestra actividad, fue la toma de conciencia de muchas empresas sobre la proximidad del año 2000 y la necesidad de integrar todos los procesos de información bajo la misma herramienta tecnológica.

2. ¿ Puede definir un elemento cuyo importe afectará tanto a clientes como a proveedores dentro de la industria de tecnología de la información?

La integración y la aproximación del año 2000 son dos temas que afectarán al Mercado en muy poco tiempo.

Lo que tal vez no haya sido comprendido totalmente, es que la tarea de corregir los sistemas requiere un esfuerzo enorme y una inversión multimillonaria. Según un informe de Gartner Group Inc. (Empresa estadounidense de investigación en tecnología), la inversión total que se requerirá en el mundo para corregir el problema se encontrará entre los 300.000 y 600.000 millones de dólares, más aún a pesar de la importancia de la inversión realizada sólo una fracción de las empresas lograrán corregir sus sistemas a tiempo, de modo que todos coinciden en que no importa la magnitud del esfuerzo realizado, nada evitará que se produzcan inconvenientes con el cambio de siglo.

En la República Argentina, las medidas que se han tomado para prevenir el problema han sido, en la mayor parte de los casos, escasas y tardías y existe un consenso más o menos generalizado de que se producirán problemas importantes. Una consecuencia no deseada, poco prevista y estudiada, es el prejuicio desde una óptica jurídica, que este fenómeno puede provocar.

Las empresas y en general los usuarios de servicios operados - en todo o en parte - por computadoras, enfrentan además del desafío técnico probablemente más importante que hayan tenido, un interesante desafío jurídico.

Tanto para proveedores como para usuarios, será de vital importancia inventariar y revisar los contratos de compra de equipos y software, así como los de provisión y mantenimiento. Resultará también de gran utilidad el análisis de los manuales y otra documentación de productos de computación así como la publicidad y materiales promocionales correspondientes a equipos y software. En este sentido es importante verificar que todo nuevo software que se adquiera sea compatible año 2000 y que el proveedor lo garantice. Esto requiere un análisis a conciencia de los textos contractuales así como la forma en que se redacten las garantías. Es también fundamental evaluar los riesgos de posible contaminación por datos provenientes de un tercero no compatible año 2000, a fin de tener un claro panorama ante hipotéticos perjuicios a producirse.

Estas tareas deberían incluirse, en lo inmediato, dentro de la actividad que realice todo letrado que asesore interna o externamente empresas, sean estas pequeñas, medianas o grandes empresas.

Ahora bien, ¿qué sucede con programas adquiridos con anterioridad a la verificación y garantías de estos extremos?. El hecho de no ser un programa compatible año 2000 derivará en una aplicación defectuosa del sistema, lo que a su vez, redundará en una deficiente prestación de servicios del que se trate. Probablemente, el proveedor o usuario, antes de producirse el prejuicio y aún no sabiendo con certeza si acaecerá o no, intentará obtener del prestador originario una garantía expresa de compatibilidad año 2000 como también lo querrá todo usuario de cualquier servicio que sepa que su prestador utiliza inexorablemente sistemas informáticos a fin de prestar el servicio del que se trate. Este incluye desde las empresas "de pager" y telefonía celular, hasta las prestadoras de servicios públicos, pasando por los bancos y demás entidades que almacenen datos, lo cual amplía infinitamente el espectro de posibles pedidos de garantía de compatibilidad así como solicitudes de garantía cruzadas, y complica un poco más el panorama, teniendo en cuenta que el negocio ya fue perfeccionado y lo que se intenta es una garantía adicional no prevista "ab initio".

Más allá de las dificultades que el tema plantea, hasta aquí estamos dentro del reinado de la autonomía de la voluntad, donde las partes pueden requerirse garantías, evaluar consecuencias e incluso intentar limitar responsabilidades, siempre dentro de un ámbito negocial no reglado.

Aún no existiendo garantía expresa, son relevantes las manifestaciones indirectas que puedan relacionarse con la situación del año 2000, ante la necesidad de interpretar si el producto está garantizado frente a posibles in compatibilidades año 2000. Por ejemplo "este software manejará correctamente años bisiestos y otros datos relacionados con fechas", asegurando que fechas incorrectas no sean ingresadas en las bases de datos.

En este punto tiene importancia la Ley de Defensa del consumidor (Ley 24.240 B.O. 15/10/93) en cuanto asigna fuerza vinculante a las precisiones formuladas en la publicidad (o en anuncios, prospectos, circulares u otros medios de difusión), así como el modo en que deben interpretarse los contratos de adhesión a favor del adherente.(arts. 8, 37, ley 24.240)

Cabe afirmar que ante perjuicios derivados por el problema del milenio, la responsabilidad puede ser tanto de índole contractual como extracontractual. El deslinde entre responsabilidad contractual y extracontractual se basa en su distinta génesis. La primera de ellas es la derivada del incumplimiento de obligaciones que tienen como fuente un acto lícito. La segunda, genera responsabilidad como sanción ante la violación del deber genérico de no dañar, con independencia de que las partes hayan estipulado las pautas de su conducta recíproca. Tal vez las dos principales diferencias que subsisten en el tratamiento de ambas órbitas sean la diferente extensión del resarcimiento y los principios en materia de carga probatoria en cuanto al factor de atribución. La extensión del resarcimiento es mayor en la órbita extracontractual, abarcando las consecuencias inmediatas, mediatas previstas o previsibles y causales que debieron resultar según las miras que tuvo al ejecutar el hecho ( arts. 903, 904 y 905 Cód. Civil), en caso de delitos y únicamente hasta las mediatas (arts. 903 y 904 Cód. Civil) en supuestos de cuasidelitos, ya sea que el factor de atribución sea subjetivo -culpa- u objetivo. Por su parte, en la órbita contractual, si el incumplimiento es culposo el deudor debe responder sólo por las consecuencias inmediatas y necesarias (art. 901 Cód. Civil) , si el factor de atribución es el dolo se extiende a las consecuencias mediatas previstas o previsibles, pero nunca a las casuales.

Así, se entiende por responsabilidad en sentido estricto el deber de reparar el daño jurídicamente atribuible causado por el incumplimiento requiriéndose para ello la concurrencia de los presupuestos de la responsabilidad: a) Incumplimiento objetivo, que consiste en la infracción del deber; b) un factor de atribución de responsabilidad o razón suficiente para asignar en deber de reparar al sujeto sindicado como deudor. Puede ser subjetivo (culpabilidad: culpa o dolo) u objetivo (teoría del riesgo, equidad, abuso del derecho); c) daño, que consiste en la lesión a un derecho subjetivo -o un interés tutelado por el ordenamiento jurídico- de la víctima del incumplimiento jurídicamente atribuible; d) una relación de causalidad suficiente entre el hecho y el daño; es decir que pueda predicarse del hecho que es causa (fuente) de tal daño.

En relación a estos será interesante el análisis del factor de atribución donde probablemente la jurisprudencia tendrá una nutrida actividad.

Si se considera que debe afrontarse la reparación económica del daño en base a un fundamento subjetivo, siguiendo la idea de culpa del Código Civil (art. 512), resultará importante todo lo expuesto anteriormente en relación a evitar la producción del perjuicio des de el aspecto tanto técnico como jurídico, a fin de probar la ausencia de culpa para eximirse de responsabilidad.

Sin embargo, si bien la culpa como factor de atribución de responsabilidad por excelencia cuenta con sólidos fundamentos históricos y normativos, el desarrollo de las distintas actividades modernas, causantes de gran cantidad de eventos dañosos, sumados a importantes consideraciones de justicia conmutativa y razones pragmáticas llevaron a un importante y abarcativo desarrollo de la atribución objetiva de responsabilidad.

En este sentido, es posible que a fin de no dejar desamparados a quien sufre injustamente un daño causado por incompatibilidades año 2000, se prescinda de la idea de culpa en el actuar del sindicato como responsable, a quien, para eximirse de responsabilidad, le resultará necesario recurrir a causales de eximición calificadas, como por ejemplo el caso fortuito (art.514 Código Civil). Sin embargo, parece difícil argumentar que el "virus del milenio" reúne los requisitos del caso fortuito, especialmente en relación a su imprevisibilidad, habida cuenta que los hechos productores del daño derivado de incompatibilidades no son imposibles de prever ni de evitar, conforme la abundante información advirtiendo sobre el tema.

Por otra parte, tampoco resultará sencillo, al menos en rasgos generales, invocar culpa de la víctima, como causal de eximición, salvo en supuestos especiales en los que la debida diligencia del damnificado en el control de sus sistemas informáticos fuera requerida y este no hubiera prestado la debida atención.

En este caso, y en el supuesto de invocarse como eximente la culpa de un tercero por quien no se debe responder, serán de vital importancia las relaciones entre creadores, distribuidores, proveedores y usuarios de software.

Dentro de esta línea, si fuera condenada una persona a pagar una indemnización por perjuicios derivados de la incompatibilidad del sistema con el año 2000, es posible que intente repetir contra quien le proveyera el insumo causante del daño. Sin embargo, en la mayoría de los casos resultará este un extremo difícil de probar, ya que no será simple detectar cuál fue el componente no compatible. En el supuesto de conseguir detectarlo, resultará fundamental a la hora de analizar la responsabilidad del proveedor la conducta de este, en particular, si ha ofrecido o no posibles soluciones para compatibilizar el sistema e informado a sus clientes de la realidad del producto.

Una herramienta que puede utilizarse por quienes hayan adquirido onerosamente insumos que resultaron no compatibles año 2000 es la figura de los vicios redhibitorios, no ya como repetición sino como acción. El Código Civil en su art. 2164 define a los vicios redhibitorios como los defectos ocultos de la cosa, cuyo dominio, uso o goce, se transmitió por título oneroso, existentes al tiempo de la adquisición, que la hagan impropia para su destino, si de tal modo disminuyen el uso de ella que de haberlos conocido el adquirente, no la habría adquirido, o habría dado menos por ella. Más allá de la importancia de tener en cuenta lo breve del plazo de prescripción (art.4041 Código Civil): 3 meses, deberá ser objeto de especial análisis el hecho de que sea o no oculto el defecto de la cosa, especialmente en atención a la calidad del adquirente, ya que si se trata de un profesional o idóneo en materia informática y la adquisición se perfeccionó en estos últimos años podría haber verificado si el sistema o producto era compatible año 2000 o no, y en tal caso será difícil que pueda alegar que el vicio era oculto ya que debía conocerlo por su profesión u oficio, circunstancia que libera de responsabilidad al enajenante (art. 2170 Código Civil). Otro fundamental punto de consideración, será la determinación del momento que el vicio se exterioriza; pues, puede no ser necesario esperar al 1º de enero del año 2000 para saber si un sistema es compatible o no y, a la inversa, en ciertos casos recién se sabrá ya avanzado el nuevo milenio.

Ahora bien, el tema de los vicios redhibitorios tiene algunas aristas complicadas. Como primera medida, hay que resaltar, que el adquirente podría haber intentado, con anterioridad a la manifestación del vicio, verificar si el sistema era o no compatible año 2000. Habrá que evaluar en cada caso la conducta del adquirente en relación al comportamiento del proveedor o vendedor, en cuanto a si ofreció "upgrades" o algún sistema para compatibilizar año 2000 el software original. Es posible afirmar que en caso de negligencia del adquirente no prosperará la acción por vicios redhibitorios.

Todas estas cuestiones, podrán ser analizadas bajo la óptica de los principios que establece la Ley de Defensa del Consumidor en materia de información, de acuerdo con las consideraciones tanto doctrinarias como jurisprudenciales modernas. En tal sentido se ha dicho: "la responsabilidad por vicios redhibitorios es, en la actualidad, interpretada como una manifestación del deber de informar al cocontratante los vicios ocultos de la cosa". "El deber de información importa, correlativamente, un deber de informarse a cargo del acreedor. Ello significa que la responsabilidad o garantía asumida por un parte, sólo es factible de ser edificada sobre la base de la ignorancia excusable o legítima de la otra". "Se tiene expresado que: 1) no constituyen vicios redhibitorios los que pueden ser advertidos por personas expertas o contratantes diligentes: la simple posibilidad de descubrir un vicio, basta para que no pueda ser considerado como oculto. 2) La inhabilidad o impericia del adquirente debe ser subsanada con el concurso de personas competentes para ilustrarlo. 3) Pero, si para establecerlo, se requiere un examen especial, el vicio es oculto. 4) Para reputar oculto un vicio, debe ser indetectable en un examen cuidadoso, pues si el vicio resultara evidente tras una prueba conforme con los usos corrientes, tal como la efectúa normalmente todo comprador de cosa semejante, el comprador que no haya procedido a esa prueba no está autorizado para pretender que el vicio era oculto".

La predisposición que encuentre el adquirente, en el proveedor-vendedor, a la hora de verificar o auditar el estado del software, condicionará su conducta futura. En el caso de prestar el proveedor un servicio de actualización y compatibilidad, no se presentarán inconvenientes de ninguna índole. En el caso contrario, será interesante estudiar si el usuario de software puede verificar las prestaciones de éste, sin correr el riesgo de violar la propiedad intelectual del autor del mismo. Es posible que a fin de verificar dichas prestaciones deba recurrir por sí, o a través de alguna persona que ofrezca servicios de compatibilidad año 2000, a la ingeniería inversa, con la consiguiente inversión hacia los códigos fuente del programa, o que incluso sin llegar a estos extremos, deba efectuar varias copias del programa, a fin de probar su funcionamiento. El art. 1º de la Ley 11.723 (modificada por Ley 25.036) protege el derecho del autor de programas de computación fuente y objeto y limita dicho derecho únicamente otorgando la posibilidad al usuario de realizar una copia de salvaguardia con la única finalidad de reemplazar al original si se pierde o deviene inútil para su utilización (art. 9). Parece razonable que se puedan requerir garantías de compatibilidad y mayores detalles de las prestaciones del software, sin embargo, prima facie, resulta contrario a la idea de protección de la propiedad intelectual que, a fin de verificar la compatibilidad, el usuario exceda sus atribuciones respecto al uso de la licencia e intente decodificar el programa o realice copias o no autorizadas del mismo.

Resulta también de singular importancia tener en cuenta las prescripciones del art. 59 de la ley 19.550, referidas a las responsabilidades de los administradores sociales cuando expresa que los administradores y los representantes de la sociedad deben obrar con "la diligencia de un buen hombre de negocios". Cabe preguntarse si un administrador que no toma las medidas necesarias en relación al tema que nos ocupa actúa con la debida atención que la ley requiere de él. Más aún, podrá inquirirse si con su omisión no pone en peligro grave a la sociedad que administra, lo que podría dar lugar a la intervención judicial de la sociedad, conforme el art. 113 del mismo cuerpo legal.

Parece razonable pensar que la verificación de la compatibilidad año 2000 se encuentra fácilmente incluida dentro de la obligación de diligencia mencionada, y en caso de violación podrá encontrarse responsables a los administradores y representantes, en forma ilimitada y solidaria, por los daños y perjuicios que ocasionen tanto a la sociedad como a terceros, pudiendo tanto la primera como los últimos accionar directamente contra el administrador social. Es factible, debido al "potencial impacto de una compañía no compatible año 2000 y lo conocido o cognoscible de los efectos de esta situación...", que "...los directivos y gerentes serán encontrados responsables por primera vez debido a fallas de sistemas. Art. 59 de la ley 19.550: Diligencia del administrador: responsabilidad. Los administradores y los representantes de la sociedad deben obrar con lealtad y con la diligencia de un buen hombre de negocios. Los que faltaren a sus obligaciones son responsables, ilimitada y solidariamente, por los daños y perjuicios que resultaren de su acción u omisión.

Demostrativo de la preocupación que existe en la materia, el Poder Ejecutivo Nacional encomendó la dirección de los temas relacionados con el Y2K a la Secretaria de la Función Pública, en cuyo marco funciona por res. SFP 152/97 del 22/08/1997 la Unidad Ejecutora 2000 ("UE-2000"), cuyos objetivos son supervisar las tareas tendientes a la búsqueda de soluciones y brindar asistencia técnica a los organismos de la Administración Pública Nacional, con el fin de garantizar el cumplimiento de las funciones esenciales y la prestación de servicios básicos a la ciudadanía. Cada Ministerio y Secretaría del Poder Ejecutivo Nacional ha debido designar un responsable de las tareas relacionadas con la Problemática del Año 2000. Complementariamente, el 22/07/1998 por dec. 856, se estableció que todos los organismos de la Administración Pública Nacional quedan obligados a elevar y someter a la aprobación de aquella Secretaría los planes adecuados para lograr que sus sistemas de información sean compatibles con el año 2000. Entre los principales objetivos a fin de lograr compatibilidad año 2000 de la UE-2000 se encuentran los Organismos Reguladores, especialmente los ligados con áreas de servicios públicos, dentro de los cuales, un tema de fundamental atención es el relacionado con los servicios públicos de Salud, para lo cual en abril de 1998 se constituyó un grupo de trabajo dentro de la UE-2000, comenzando una investigación acerca de cuál sería el equipamiento que podría resultar afectado, clasificándolo sobre la base de su criticidad y abarcando tanto las acciones de diagnóstico como de tratamiento de pacientes.

En este mismo sentido, el Presidente de la Nación con fecha 1/10/1998 dirigió una comunicación a los Gobernadores de las provincias, sugiriéndoles la adopción de medidas análogas en los ámbitos provinciales y municipales, y en el ámbito internacional, comenzó a funcionar un grupo de trabajo integrado por los países del MERCOSUR, Chile y Bolivia en septiembre de 1998.

En relación a las sociedades que cotizan en Bolsa, la necesidad de verificar que sus sistemas sean compatibles año 2000 surge de las res. generales 309/98 de la Comisión Nacional de Valores (CNV) que impone a dichas entidades la "obligación de adecuar los sistemas informáticos utilizados en su actividad a fin de asegurar su correcto y normal funcionamiento con posterioridad al 31 de diciembre de 1999". Por su parte la entidades autorreguladas MERVAL , Mercado Abierto Electrónico y Mercados a Término) han presentado los planes de acción que están llevando adelante, solicitados por la CNV. Por otra parte a través de la Organización Internacional de Comisiones de Valores la CNV sigue los lineamientos dictados a nivel internacional. En este sentido la US Securities and Exchange Commission (SEC) -equivalente norteamericano de nuestra CNV- , impuso la obligación a empresas que cotizan en Bolsa a incluir en sus informes anuales detalles sobre sus problemas año 2000.

Demostrando su preocupación por los futuros conflictos derivados de las posibles incompatibilidades año 2000, la SFP, anunció su intención de presentar un proyecto de Ley a fin de limitar responsabilidades civiles derivadas de la materia del análisis.

En igual dirección el 26 de marzo de 1999 en EEUU la Comisión Judicial del Senado habría aprobado un proyecto de ley dirigido a promover la puesta en marcha y adecuación para el año 2000, desalentando el derroche en diversificación de recursos para costos causídicos por el año 2000. El proyecto americano establece un período de gracia de 90 días a fin de resolver los problemas derivados del año 2000 autorizando la posibilidad de solicitar alguna Resolución Alternativa de Disputas. Limita los pedidos de acción de clase así como la imposición de daños punitivos e incluye protecciones especiales para pequeños comercios y particulares. La propuesta cuenta con el apoyo de grupos industriales. Sin embargo, el proyecto es resistido por el Senado, distintas entidades dedicadas al Derecho y la Administración del Presidente Clinton.

Estas pautas no hacen más que resaltar la importancia del problema, en cuanto a la exigencia de "due dilligence". Será fundamental a la hora de evaluar los perjuicios y de encontrar responsables la diligencia que se haya puesto en acotar los riesgos y buscar alternativas para solucionar hipótesis de conflictos, por ello no debe minimizarse la importancia de prevenir. Por su parte, la sola circunstancia de hablar de limitación de responsabilidad lleva a concluir en lo trascendente del tema de los daños derivados de incompatibilidades año 2000.

En relación a la posibilidad de asegurar este riesgo, en los EEUU muchas compañías creen que los riesgos relacionados con el año 2000 son esencialmente inasegurables en razón de su magnitud, sin embargo parecería que existen en aquel país dos compañías que ofrecen específicamente seguros para cubrirlos, pero la mayoría de las compañías de seguros están incluyendo la cobertura de los riesgos de Directores y Ejecutivos relativos al problema año 2000, cuando ese tipo de pólizas se presenta para su renovación. Mientras algunos reaseguradores están considerando excluir los problemas del año 2000 de sus pólizas, otros han comenzado a hacerlo ya mismo, particularmente cuando cubren riesgos de interrupción de negocios, errores y omisiones, responsabilidad sobre productos y responsabilidad profesional. Similar tendencia parece advertirse en el mercado asegurador argentino.

Los técnicos en la materia plantean como inevitable, con mayor o menor magnitud, el acaecimiento de perjuicios derivados de la no compatibilidad de los sistemas con el cambio de milenio. Esto coloca a los estudiosos del Derecho ante un panorama inagotable de conflictos que indefectiblemente habrán de producirse.

Ley 24.240:

Art. 8. Efectos de la Publicidad. Las precisiones formuladas en la publicidad o en anuncios prospectos, circulares u otros medios de difusión obligan al oferente y se tienen por incluídas en el contrato con el consumidor.

[ En los casos en que las ofertas de bienes y servicios se realicen mediante el sistema de compras telefónicas, por catálogos o por correos, publicados por cualquier medio de comunicación deberá figurar el nombre, domicilio y número de CUIT del oferente] (TEXTO SEGÚN LEY 24.787.)

Art.37. Interpretación. Sin perjuicio de la validez del contrato, se tendrán por no convenidas:

1. Las cláusulas que desnaturalicen las obligaciones o limiten la responsabilidad por daños;
2. Las cláusulas que importen renuncia o restricción de los derechos del consumidor o amplíen los derechos de la otra parte;
3. Las cláusulas que contengan cualquier precepto que imponga la inversión de la carga de la prueba en perjuicio del consumidor.

La interpretación del contrato se hará en el sentido más favorable para el consumidor. Cuando existan dudas sobre los alcances de su obligación, se estará a la que sea menos gravosa.

En caso en que el oferente viole el deber de buena fe en la etapa previa a la conclusión del contrato o en su celebración o transgreda el deber de información o la legislación de defensa de la competencia o de lealtad comercial, el consumidor tendrá derecho a demandar la nulidad del contrato o la de una o más cláusulas. Cuando el juez declare la nulidad parcial, simultáneamente integrará el contrato, si ello fuera necesario

Desde el punto de vista técnico el problema de Y2k podemos decir, que en mayor o menor medida los perjuicios originados en la incompatibilidad de los sistemas frente al cambio de milenio serán inevitables.

Ante ello se abre un panorama inmenso de conflictos que pueden llegar a surgir en el transcurso del cambio de milenio, sin olvidar que ya hay varios casos planteados en la justicia.

Este trabajo ha pretendido brindar una visión del tema en general, describiendo su origen, sus aspectos técnicos. Por otra parte, esbozamos las acciones emprendidas por diferentes sectores de la sociedad argentina y también del ámbito internacional. Pasando por algunas de las herramientas y soluciones que ofrecen ciertos organismos y empresas privadas.

Luego de este sucinto análisis y sin pretender ahondar demasiado en los aspectos tecnológicos, pensamos que las soluciones legales dependerán en gran medida de las circunstancias del caso, así como de las figuras jurídicas abstractas.

Siendo fundamental la prevención jurídica y el diagnóstico de este tipo de problemas, para evitar eventuales situaciones conflictivas, o aún cuando estas ocurran estar preparados y contar con los conocimientos y herramientas que lleven a la mejor resolución del problema.

BIBLIOGRAFIA

• Clarín - Información General - 14 de marzo de 1999 - pag. 52 - "Cómo se prepara el país ante la crisis de las computadoras"

• Clarín - Información General - 14 de marzo de 1999 - pag. 55 - "Un impacto multimillonario"

• Clarín - Económico 30 de mayo de 1999 - pag. 15,16 - "Se avecina el día D"

• Clarín - Información General - 30 de mayo de 1999 - pag. 46,47 - "Cómo se prepara el mundo para el efecto 2000"

• Clarín Digital- Sociedad - 31 de mayo de 1999 - "Los bancos dicen que no le temen al cambio de siglo"

• Clarín - Información General - 6 de junio de 1999 - pag. 40,41 - "Las empresas chicas no están listas para el 2000"

• Damation Vol. 6 Nº5 1997 - "La solución de la bala de plata"

• Damation Vol. 6 Nº8 1997 - "Estimado Sr. Gates"

• Damation Vol. 7 Nº1 1998 - "Pánico en el año 0 - Una bendición oculta"

• Damation Vol. 7 Nº2 1998 - "No hay mal que por bien no venga"

• Damation Vol. 7 Nº4 1998 - "Una propuesta no tan humilde"

• Damation Vol. 7 Nº8 1998 - "NT 5.0 Los Usuarios se ocuparán después del año 2000"

• Damation Año 7 Nº11 1998 - "Qué sorpresas caerán de la piñata del Año 2000"

• Damation Vol. 7 Nº12 1998 - "Software América - El problema del Año 2000 impulso las ventas"

• Damation Vol. 8 Nº2 1999 - "Herramientas del Año 2000"

• La Ley Año LXIII Nº114 - 16 de junio de 1999 - "Problema informático del año 2000 ¿un "milenio" sin soluciones?"
• Ley 19.550 Sociedades Comerciales B.O. 25/04/72
• Ley 24.240 Defensa del Consumidor B.O. 15/10/93
• Código Civil Argentino - arts. varios
• Internet:

www.sfp.gov.a

www.map.es

*INTRODUCCION ------------------------------------------------------------------------------------- 1

*PROBLEMAS EN SISTEMAS EMBEBIDOS -------------------------------------------------- 2

*PROBLEMAS OCULTOS -------------------------------------------------------------------------- 3

*SISTEMAS EMBEBIDOS: DEL CHIP A LA CIUDAD ---------------------------------------- 4

*EFECTOS DEL 2000 EN EL HOGAR ----------------------------------------------------------- 4

*Y2K: SITUACION EN LOS DISTINTOS PAISES

COMO SE PREPARA EL MUNDO PARA EL EFECTO DEL 2000 ----------------------- 4

*INTERNACIONAL

GRUPO BINACIONAL CON LA REPUBLICA DE CHILE ---------------------------------- 5

*GRUPO AD- HOC MERCOSUR, CHILE Y BOLIVIA... ------------------------------------- 6

*FORO IBEROAMERICANO SOBRE: LA RESPONSABILIDAD

DEL ESTADO FRENTE... --------------------------------------------------------------------------- 6

*FORO Y2K AMERICA DEL SUR ----------------------------------------------------------------- 6

*GRUPO AD-HOC MERCOSUR, CHILE Y BOLIVIA ----------------------------------------- 6

*FASE I Y II --------------------------------------------------------------------------------------------- 7

*GRUPO BINACIONAL CON LA REP. DE CHILE -------------------------------------------- 7

*ETAPA I Y II -------------------------------------------------------------------------------------------- 8

*FORO Y2K AMERICA DEL SUR ----------------------------------------------------------------- 8

*AVANCES REALIZADOS -------------------------------------------------------------------------- 8

*ACCIONES EN CURSO ---------------------------------------------------------------------------- 9

*COMO AFECTARA EL PROBLEMA EN ARGENTINA ------------------------------------ 10

*SECTORES

TRANSPORTE AEREO ------------------------------------------------------------------------------ 11

TRANSPORTE MARITIMO -------------------------------------------------------------------------- 11

TRANSPORTE TERRESTRE ----------------------------------------------------------------------- 11

*ENERGIA ------------------------------------------------------------------------------------------------ 11

*TELECOMUNICACIONES -------------------------------------------------------------------------- 12

*FINANZAS ----------------------------------------------------------------------------------------------- 12

*SALUD ---------------------------------------------------------------------------------------------------- 12 *SEGURIDAD SOCIAL -------------------------------------------------------------------------------- 12 *RECAUDACION ---------------------------------------------------------------------------------------- 12

*ANSES

ANTECEDENTES --------------------------------------------------------------------------------------- 13 *ESTRATEGIA DE ANSES ANTE EL CAMBIO DEL MILEÑO ------------------------------ 13

*PLANES DE CONTINGENCIA ---------------------------------------------------------------------- 14

*CONTROL ------------------------------------------------------------------------------------------------ 14

*INVESTIGACION ESPECIAL DIARIO CLARIN, 31/05/99... --------------------------------- 15

*RETENIENDO LOS FONDOS ----------------------------------------------------------------------- 15

*CARTERA DE DEUDORES -------------------------------------------------------------------------- 16

*FALTA UNA PRUEBA CRUCIAL ------------------------------------------------------------------- 16

*HERRAMIENTA PARA EL AÑO 2000 ------------------------------------------------------------ 17

*LOS PRESUPUESTOS EN 1998 BUSCARON SALVAR EL PROBLEMA -------------- 19

*EL Y2K IMPULSO LAS VENTAS ------------------------------------------------------------------- 19

*II JORNADA PARA LA MODERNIZACION TECNOLOGICA DEL ESTADO ------------ 20

*EXPOSICION DE PETER DE JAGER ------------------------------------------------------------- 20

*CONCLUCIONES DE LA JORNADA --------------------------------------------------------------- 32

*SECRETARIA DE LA FUNCION PUBLICA CREACION DE LA,

UE-2000 ----------------------------------------------------------------------------------------------------- 36

*ACCIONES ENCARADAS POR LA SECRETARIA

DE LA FUNCION PUBLICA ---------------------------------------------------------------------------- 38

*METODOLOGIA DE TRABAJO SOBRE LA

PROBLEMÁTICA DEL AÑO 2000 ------------------------------------------------------------------- 41

*SECRETARIA DE LA FUNCION PUBLICA ------------------------------------------------------ 41

*SUBSECRETARIA DE TECNOLOGIA INFORMATICA, UE-2000 ------------------------- 41

*INTRODUCCION --------------------------------------------------------------------------------------- 41

*FASE 0 ---------------------------------------------------------------------------------------------------- 41

*FASE 1 ---------------------------------------------------------------------------------------------------- 41

*FASE 2 ----------------------------------------------------------------------------------------------------- 42

*FASE 3 ---------------------------------------------------------------------------------------------------- 42

*FASE 4 ---------------------------------------------------------------------------------------------------- 42

*AÑO 2000 DESCRIPCION --------------------------------------------------------------------------- 43

*AÑO 2000 ENFOQUE DEL PROBLEMA --------------------------------------------------------- 44

* ETAPA 1 Y 2 -------------------------------------------------------------------------------------------- 44

* PLAN DE CONTINGENCIAS ----------------------------------------------------------------------- 45

QUE ES UN PLAN DE CONTINGENCIAS? ------------------------------------------------------ 45

*PLANES DE ACCION -------------------------------------------------------------------------------- 45

*AÑO 2000 COSTOS ---------------------------------------------------------------------------------- 46

*AÑO 2000 DEFINICION COMPATIBLE --------------------------------------------------------- 48

*AÑO 2000 TAREAS QUE NO PUEDEN DELEGARSE... ---------------------------------- 49

*AÑO 2000 PRINCIPALES TECNICAS UTILIZADAS... ------------------------------------- 49

*SISTEMAS NO INFORMATICOS ----------------------------------------------------------------- 50

*USUARIOS DE PC ------------------------------------------------------------------------------------ 50

*PROYECTOS PARA ENFRENTAR AÑO 2000 ----------------------------------------------- 52

*NORMAS PARA ORIENTAR Y REGULAR PLANES DE ACCION... -------------------- 52

*EL IMPACTO DEL AÑO 2000 ---------------------------------------------------------------------- 56

*DESCRIPCION DEL PROBLEMA ----------------------------------------------------------------- 56

*ILUSTRACION DEL PROBLEMA ----------------------------------------------------------------- 57

*METODOLOGIAS PROPUESTAS ---------------------------------------------------------------- 57

*CONSIDERACIONES ERRONEAS --------------------------------------------------------------- 58

*ESTRATEGIAS DE SOLUCION ------------------------------------------------------------------- 59

*RECOMENDACIONES FINALES ----------------------------------------------------------------- 59

*EL PROBLEMA DEL AÑO 2000 ------------------------------------------------------------------- 61

*SERVICIOS Y SUMINISTROS EXTERNOS --------------------------------------------------- 61

*FUNCIONAMIENTO HABITUAL Y

RELACION CON OTROS PROYECTOS -------------------------------------------------------- 62

*INVENTARIO COMPLETO DETALLADO ------------------------------------------------------ 63

*ESTIMACION DE RECURSOS

ESTRATEGIAS Y PLAN DE TRABAJO ---------------------------------------------------------- 63

*REALIZACION DE CAMBIO, PRUEBAS E IMPLANTACION ------------------------------ 64

*ACCIONES DEL CONSEJO SUPERIOR DE INFORME ------------------------------------ 64

*SE AVECINA EL DIA "D" ---------------------------------------------------------------------------- 65

*FALLAS PROPIAS Y AJENAS ------------------------------------------------------------------- 65

*PROVEEDORES ALTERNATIVOS --------------------------------------------------------------- 66

*LA "BOMBA DEL 2000" ---------------------------------------------------------------------------- 66

*VISITAS PERSONALES ---------------------------------------------------------------------------- 66

*MAXIMA PRIORIDAD -------------------------------------------------------------------------------- 66

*LOS BANCOS Y CAJEROS AUTOMATICOS -------------------------------------------------- 67

*PyMes ---------------------------------------------------------------------------------------------------- 67

*PyMes CARTA MODELO --------------------------------------------------------------------------- 67

*PROVEEN LITIGIOS POR UN BILLON DE DOLARES ------------------------------------- 68

*EE.UU. "ALTO RIESGO" ---------------------------------------------------------------------------- 68

*EMPRESAS PUBLICAS --------------------------------------------------------------------------- 68

*SISTEMAS LOGICAL -------------------------------------------------------------------------------- 69

*MACOLA SOFTWARE --------------------------------------------------------------------------- 69

*PROBLEMA INFORMATICO DEL AÑO 2000,

ANALISIS DE LAS CUESTIONES LEGALES -------------------------------------------------- 70

*NOTAS---------------------------------------------------------------------------------------------------- 75

*CONCLUSION ---------------------------------------------------------------------------------------- 76

*BIBLIOGRAFIA ----------------------------------------------------------------------------------------- 77

*INDICE ---------------------------------------------------------------------------------------------------- 78