La pesadilla informática del año 2000, engendrada
por la dificultad de muchos sistemas para manejar fechas en el
próximo siglo, viene enfrentando a los expertos en un
complicado debate acerca de la necesidad y urgencia de corregir
millones de líneas de código (instrucciones en lenguaje
de programación), a un costo que ronda el dólar y medio
por línea.
Entre tantas opiniones contrastantes, un caso de carne y hueso
resulta particularmente útil para comprender la realidad del
problema, las dificultades de solución y el camino que falta
recorrer antes del próximo milenio.
En una muestra de decisión y previsión, la filial
local del banco holandés ABN Amro encaró la
cuestión comenzando por la fase lógica de
análisis (o plan, como lo denominan ellos) para determinar
dónde pueden estar los problemas, cuál sería su
impacto y cómo puede corregirse en tiempo y forma.
André Peels, gerente regional de Información del
banco, a cargo de 12 países de América latina y el
Caribe, conversó con MERCADO acerca de la experiencia del ABN
Amro.
– ¿Cómo comenzó el proyecto para analizar el
problema del año 2000 en su organización?
– Se trata de un problema único, que se presenta una sola
vez, y por tanto es perfecto para hacer un outsourcing. Este es un
tema en el cual a nosotros, como banco, no nos interesa tener o
formar especialistas. Pero tenemos un plazo final que cumplir, fijado
por la organización: el 1º de diciembre de 1998. Porque,
además del problema con el primer día del 2000, tenemos
un montón de problemas con el 1º de enero de 1999.
Sucede que en los últimos 20 o 30 años hubo muchos
sistemas que usaron el 99 como un código de proceso, con un
significado distinto del año, un indicador de operaciones
completamente disímiles. Era realmente común,
allá por los ´60, usar este número como un
código. Y por tanto no es muy buena idea esperar al ´99 para
solucionar el 2000.
– ¿Cuándo decidieron recurrir a un outsourcing?
¿Habían evaluado el impacto del problema previamente?
– Siendo un banco, no había ninguna duda de que el problema
iba a afectarnos. Es un problema muy real y muy fácil de
verificar.
Para este proyecto elegimos a la firma Origin, cuyo modelo de
trabajo tiene fases, que resultan muy convenientes para nosotros. La
metodología de ABN Amro es igual a la de Origin, un modo de
hacer las cosas que responde a la cultura del banco desde la casa
matriz. Además, uno de los puntos para calificar fue que la
firma estuviera al tanto del problema de 1999.
– ¿Cuál es la estimación de costos y tiempos
del proyecto?
Debería estar terminado todo para el 1º de diciembre
de 1998, pero la fase del plan que se está realizando ahora
tiene como fecha limite el 1º de septiembre de este año.
El gasto posterior no se puede calcular, pero no ha de ser mucho, ya
que hay una cantidad de cosas que son simples de cambiar, donde lo
que hay que hacer es exigirle al proveedor que asegure que el
software sea año 2000 compatible. En el plan se hace muy claro
que 90% del problema es con proveedores, por lo cual el costo de
reparación no es para nosotros.
Otra parte del problema es con software que viene de la casa
central, lo que tampoco es un gasto nuestro. La matriz completa que
hizo Origin involucra a unas 150 aplicaciones, pero la
combinación de componentes asciende a unos 400 elementos
informáticos que deben chequearse. Realmente es un trabajo muy
completo de inventario de los componentes de la operación.
¿Qué se hace con todo eso? ¿Se repara?
– El plan determinará dónde están los
problemas, y se verá, con el transcurso natural del proceso de
recambio de los sistemas del banco, sobre qué hay que actuar,
reemplazar o actualizar. Pero lo propio es muy poco.
¿Entonces, el plan les indica a quién deben llevar el
reclamo?
– Exactamente, es la mayor parte del trabajo. Es lo bueno de esta
metodología, nos da un inventario muy detallado de los
componentes informáticos, y nos indica qué debemos
hacer.
¿Qué se hace cuando un sistema no aprueba el
requerimiento?
– Todo depende del caso. Si un sistema no está bien hoy,
pero va a estar corregido durante este año, esperamos. Por
otra parte, hay relaciones con proveedores que son muy importantes, o
en las que no es fácil buscar una alternativa. Eso se maneja,
pero es importante saber cuál es la situación.
Además, hay que considerar que el problema no abarca
sólo al software; hay cosas que son hardware, como Bios de PCs
y otras cosas.
– Además de los proveedores, están las empresas con
las que el banco intercambia datos y comparte negocios. ¿No
representan también un riesgo operativo si no están
preparadas para el año 2000?
– Bueno, en cierto sentido es lo mismo. Con ellos establecemos un
compromiso contractual como con los proveedores.
– ¿Cuál fue el mayor problema que encontraron hasta
ahora en la aplicación del proyecto?
– Definitivamente, el problema más grande es que toda la
gente involucrada dentro de la compañía tenga la
información a tiempo. Hay que tener presente que no se trata
solamente de la gente en la Argentina, sino también de
Panamá, Venezuela, Aruba o alguno de los otros 12
países que deben volcar los datos para tener terminado el
proyecto de la región. Luego, otro factor de retraso y
complicación es la tardanza de algunos proveedores de software
para responder a los requerimientos sobre la compatibilidad de sus
sistemas. Y esto no ocurre sólo con empresas latinas,
pequeñas o grandes. Las hay de todo tipo y origen. Y
también están las compañías que dependen
de otras, y por tanto tienen que consultar si la combinación
tiene algún problema. Resulta muy difícil analizar
todos los entrecruzamientos.
El otro lado del proyecto
Para comprender la dimensión total del proyecto de ABN Amro
vale la pena escuchar la opinión de los expertos de la
consultora contratada, Origin.
Raul Sventuiz es, precisamente, el líder de proyecto
asignado al caso. “Origin cuenta con toda una metodología para
enfrentar el problema, denominada Sol 2000, un método que
requiere procedimientos y acciones perfectamente encuadrados,
además de profesionales y un soporte de experiencia basado en
casi cinco años de trabajo sobre el problema del año
2000”, explica.
Esta solución tiene dos fases, una de evaluación y
otra de actualización. En el ABN Amro se está aplicando
la primera parte, cuyo producto final es un plan integral de
actualización de los componentes de informática
(aplicaciones, hardware, software de base y todas las otras partes
que componen la operación de sistemas de una
organización).
“En el caso de las aplicaciones el plan determina qué hay
que modificar y dónde, cuál es el esfuerzo y
cuánto costará. Finalmente, dentro del plan de
conversión están las estrategias a seguir
(cuándo conviene reemplazar o convertir). En definitiva, la
decisión queda en manos del cliente”, afirma Sventuiz.
“No es casual que las empresas que están tomando la
iniciativa con respecto a la cuestión del año 2000 sean
subsidiarias de multinacionales, donde existe más conciencia
del problema. Hoy, en la Argentina, hay grandes bancos y organismos
del Estado que aún están en veremos”, advierte.
“Y el problema más grande es que no existe mentalidad de
plan, se hacen planes porque se impone, es una obligación…
pero falta la mentalidad para llevarlos a cabo. Por eso, más
allá de la metodología, existe la necesidad de acomodar
el proyecto a la cultura latinoamericana.”
“En el caso del ABN Amro esto se evidencia con el nivel de
respuesta de los proveedores, lo que ocasiona bastantes demoras.
Luego, cuando analizamos estos hechos vemos que hay muchos
proveedores que no tienen la solución (o están
esperando para dar una solución más concreta). Sabemos
que no están preparados para el 2000 al estudiar los
componentes. La reacción a la falta de respuesta queda a cargo
del cliente. En algunos casos críticos se puede pedir el
reemplazo del proveedor y en otros puede haber interacción con
un proveedor que no tiene la solución, y en esos casos el plan
provee soluciones alternativas, como la implementación de
interfases (break year) que acomoden el tratamiento de fechas.”