La tecnología asiste al combate euro-peseta

Al margen de los impactos en la economía de la introducción de la nueva moneda debe destacarse el que se producirá en los sistemas de información de las empresas que operan en la zona euro. Un impacto que puede clasificarse en dos grandes grupos: uno lógico (asociado con el software de aplicación y los soportes de los datos, BBDD, tablas y ficheros); y otro físico (relacionado con el hardware que maneja dinero en efectivo).

A juicio de Alfonso Mur, socio de Andersen, “el impacto se origina por circunstancias como la convivencia temporal electrónica (desde enero de 1999) y físicamente (desde enero de 2002) de dos monedas; la necesidad de gestionar moneda fraccionaria (céntimos de euro) y de representar los importes con dos decimales; el efecto de redondeo que se produce en la conversión de pesetas a euros y viceversa; y el distinto tamaño tanto de físico como de peso entre los dos tipos de monedas y billetes”.
La decisión informática al euro se ve claramente influenciada por las decisiones de negocio que tendrán claros impactos tecnológicos como la flexibilidad para el desarrollo de sistemas que den soporte informático a nuevos productos, la interconexión a redes europeas, o la tecnología que de soporte a nuevos canales de distribución que impondrán un mercado más globalizado al que asistiremos en breve.
Si bien el proceso de adaptación a la moneda única no representa tanta complejidad como meticulosidad, esfuerzo y paciencia, el tema se agrava por la falta de tiempo. A menos de cuatro meses para la llegada del euro en efectivo no hay que desperdiciar ningún día.
Para el socio de Andersen, la clave está en identificar el impacto real en los sistemas. “Hay que identificar aquellas aplicaciones que almacenan, procesan, calculan, informen o funcionen en relación con el dinero en efectivo o el dinero electrónico. Además de, si procede por el tipo de empresa, el hardware dinerario, aquel que funciona, recauda o dispensa dinero en efectivo (cajas automáticas, cajeros, terminales de venta, videojuegos, parkímetros)”.
Acto seguido habría que establecer si el afecta a terceras partes (cómo clientes, bancos, proveedores, organismos oficiales o cualquier tercero con el que de alguna forma intercambiamos información con importes dinerarios) y en que medida lo hace. En este caso Mur cree interesante conocer “la estrategia y el calendario de conversión que ha decidido la tercera parte, o la que dicha parte espera de nosotros. Además, resultaría muy útil conocer si las Administraciones Públicas, Administraciones Locales, o Asociaciones Gremiales han publicado recomendaciones o normas sobre los tiempos y formas de realizar la conversión”. En función de los datos obtenidos tras los pasos anteriores, se establecerá la estrategia a seguir y las decisiones adoptadas. Estas decisiones no son estrictamente tecnológicas si no que deberá participar en ellas además de la Dirección, los responsables de áreas como marketing, comercial, RRHH, etc. y ser respetuosas con los acuerdos generales o gremiales sobre la adaptación al euro. “En este punto -señala el socio de Andersen-, es cuando deben responderse preguntas como si se cierra el presente ejercicio contable en pesetas o euros, si se convierten los datos y operaciones de los clientes antes del 1 de enero de 2002, si se convierte el histórico o se deja en pesetas, o si ya es el momento para informar en euros a terceros”.
A continuación los responsables del proyecto deberán elaborar un plan detallado de acción que contenga las acciones e hitos relevantes para la adaptación de los sistemas afectados, con especial atención sobre las fechas acordadas o establecidas con terceros. “La ejecución del plan estará estrechamente relacionado con la estrategia decida y con los calendarios acordados. La adaptación de aplicaciones y máquinas dependerá de si son propias o de proveedores, de los contratos de mantenimiento establecidos con ellos y de los recursos disponibles, etc.”, comenta Alfonso Mur.
La última fase está relacionada con las pruebas de las adaptaciones realizadas, un proceso que resulta imprescindible para testimoniar que todo va a funcionar correctamente. Además de probar los cambios realizados en aplicaciones y maquinarias, habrá que hacer un seguimiento periódico del funcionamiento de las mismas hasta que se trabaje exclusivamente en euros.
Entre las aplicaciones más sencillas de adaptación se encuentran aquellas que se haya acordado convertir directamente a euros sin convivencia de pesetas. Lo cual supone que se establece una fecha a partir de la cual se convertirá todo en euros y sólo se trabajará en la nueva moneda, la nómina es una aplicación de este tipo. Entre las más complejas, sin embargo, se sitúan aquellas que soportarán movimientos, apuntes o asientos en las dos monedas durante el período de convivencia y que una vez acabado este deberán convertir todo a euros. (contabilidad, facturación, compras, almacén, recibos - clientes, pagos - proveedores, caja, bancos, etc) tendrán que gestionar la existencia de operaciones o apuntes en dos monedas. - Durante el período de convivencia habrá que identificar en que moneda se realiza la operación, el apunte o el asiento contable, en una gestión multidivisa.
Complejidad también representan los Datawarehouse, básicamente porque deberán gestionar adecuadamente las sincronías de adaptación del resto de aplicaciones que alimenten el sistema.
Uno de los principales problemas lo representa la convivencia de la peseta y el euro y la posterior desaparición de la peseta. Durante dos meses los programas de ordenador relacionados con importes tendrán que gestionar la existencia de operaciones o apuntes en dos monedas. Sin embrago, en aquellas aplicaciones que están diseñadas como multidivisa no existe un problema real de convivencia. A la finalización de este período se realiza una conversión de pesetas a euros y se redenominan las pesetas como euros. Por su parte, sobre aquellas aplicaciones que en su nacimiento estaban pensadas para gestionar una única moneda existen diferentes perspectivas y alternativas de solución. Tal como apunta Alfonso Mur, “se acuerda establecer una fecha de conversión a euros sin convivencia de pesetas y a partir de entonces se convierte a euros y se trabaja sólo a euros. Se trata de una estrategia de huida hacia delante que se puede realizar preferentemente en aplicaciones que no tengan interfaces con terceros. Cuando no quede más remedio que gestionar temporalmente las dos monedas, deberán hacerse ajustes en la aplicación”. Para el socio de Andersen ya no es recomendable proceder a la adaptación para una gestión multidivisa, “existe otra alternativa -comenta Mur-, que consiste en alterar el esquema de datos para que permita identificar en que moneda está cada registro u operación y conservarla o registrarla en su moneda original. Después deberá decidirse cuál de las dos monedas se utilizará como base y realizar los ajustes necesarios en los programas para que la aplicación presente o calcule según el indicador de moneda”. En cualquier caso finalizado el período de convivencia se deberán deshacer los cambios y realizar una conversión definitiva de lo que esté en pesetas a euros. De la misma forma, no debe dejarse de lado la cuestión del redondeo en l