Exposición de Peter de Jager

 

Secretaría de la Función Pública

Jueves 10/07/1997 - Auditorio del Banco Hipotecario Nacional

 

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

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.

 

 

Conclusiones de la Jornada

 

 

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