Sumatoria 2

Título:

Aguirre Newman

Introducción:

La misión de la empresa formulada por Santiago Aguirre y Stephen K. Newman, Presidentes del grupo Aguirre Newman es: “Ser reconocidos internacionalmente como la firma líder en asesoramiento, implementación y gestión de proyectos inmobiliarios de España y Portugal”.

Los directivos del grupo Aguirre Newman, debido tanto a la entrada prevista del euro como el fuerte crecimiento del grupo, se vieron obligados a cambiar sus aplicaciones de software de gestión y financieras. El grupo había desarrollado una aplicación para la facturación y había adquirido un programa para la contabilidad, además utilizaban innumerables hojas de cálculo para hacer tanto el seguimiento de los proyectos, como el presupuestario. En el año 2000 iniciaron un proyecto de evaluación de distintas alternativas.

Las empresas que integraban el grupo Aguirre Newman se dedicaban a actividades muy diversas, lo que conllevaba que cada una de ellas tuviera necesidades distintas. Había empresas tipo holding, cuyo objetivo básico era la prestación de servicios centrales y la asunción de los gastos generales del grupo para, posteriormente, repercutirlos; empresas de servicios inmobiliarios, que realizaban servicios de asesoría inmobiliaria y cuyos ingresos provenían de la intermediación; y empresas que trabajaban para proyectos.

La contabilidad la gestionaban mediante Dimoni sobre Microsoft DOS, este entorno no soportaba el entorno multidivisa. El registro de los movimientos de la contabilidad se realizaban de forma manual en todas las compañías, además de la aplicación de contabilidad no estaba integrada con ninguno de los otros sistemas, lo que obligaba a reprocesar todos los datos que se introducían en una aplicación en las demás.

Las compañías del grupo contaban con planes contables distintos. Los procesos de cierre se hacían coincidir en todas las empresas del grupo y se llevaban a cabo sin una periodicidad fija.

La aplicación de contabilidad no permitía traspasar los saldos entre ejercicios sin hacer cierre contable, por lo que era necesario realizar cierres provisionales; para la facturación, tanto de clientes como de proveedores, se había desarrollado una aplicación denominadas ANIS, que se utilizaba junto con una herramienta estándar de gestión de base de datos denominada FileMaker. Con ANIS se emitían las facturas a los clientes y las solicitudes de compra a los proveedores, y se realizaba el seguimiento de los clientes y los proveedores. ANIS no estaba integrada en la aplicación para la gestión de la contabilidad lo que obligaba a introducir la información en el programa de contabilidad y llevar a cabo las conciliaciones necesarias.

Además de las aplicaciones anteriormente descritas, se utilizaban distintas aplicaciones de banca electrónica de diferentes entidades financieras que permitían consultar los saldos y movimientos, emitir órdenes de pago y cobros, que posteriormente debían contabilizarse en la aplicación de contabilidad.

El uso de todo este conjunto de herramientas implicaba la necesidad de desarrollar proceso manuales para cubrir sus deficiencias, lo que conllevaba que las tareas de control fueran muy laboriosas y que se invertirá mucho tiempo en ellas. Para una empresa embarcada en rápido crecimiento, la situación era muy difícil.

Desarrollo:

Para la selección del software más apropiado se formó una comisión integrada por miembros de la dirección del grupo. De ella formaban parte Álvaro Martínez, Director Financiero, y Javier Echeverría, Director General. Este grupo de personas debía analizar los ERPs y existentes en el mercado y seleccionar el más adecuado para el grupo.

Se tenía un requerimiento básico: el nuevo sistema de información debía permitir el control de los distintos proyectos. Este requisito, unido al hecho de que no tenían inventarios, les llevo a descartar caso desde el principio la posibilidad de comprar un software que estaba más orientado al control de producción e inventarios.

Otro de los programas analizados, Baan, incluía un análisis más desarrollado de proyectos. Sin embargo, fue descartado por ser menos parametrizable y adaptable a las necesidades reales, así como por tener un entorno menos amigable para los usuarios finales.

Asimismo, se analizaron otras soluciones existentes en el mercado, que fueron descartadas por cuestiones de precio o dimensión, como fue el caso de JD Edwards y Oracle; finalmente evaluaron el software Daamgard Axapta, desarrollado por la empresa

...