Lo que nunca deberías hacer al implantar un nuevo ERP en una empresa de Construcción

Las recomendaciones que a continuación especifico no pretenden ser un compendio metodológico sobre como abordar una exitosa  implantación de un sistema de gestión integrado (ERP) en una empresa de Construcción , si no que tiene como cometido considerar las diversas alternativas que tenemos a nuestra disposición para el desarrollo de la misma, al objeto de que nos ayuden a trazar el camino más adecuado. 

Es muy importante tenerlos presentes, sobre todo para que el conjunto de la implantación no sufra desviaciones ni esfuerzos innecesarios del rumbo que debemos de trazar.

Veamos algunos de ellos:

1.- Solo dedicar esfuerzos en la migración de datos de la empresa matriz y minusvalorar el resto sociedades.

Es muy habitual que una empresa  tenga abiertas diversas razones sociales complementarias a la empresa matriz que tienen sus respectivos tratamientos contables. Aunque la mayoría de ellas son de carácter patrimonial, su migración y tratamiento contable son necesarios. El apartado de cambio contable está circunscrito al cambio de la contabilidad en la empresa matriz y muchas veces este aspecto que hemos citado, se pasa por alto. Aunque el esfuerzo más importante en las tareas de migración se realiza con la empresa motor y con su migración se asienta el conjunto del sistema de información, ello no quiere decir que el resto de las empresas no halla que migrar y por lo tanto lleve su trabajo (mucho más, de lo que imaginamos a priori).

En definitiva, si existe esta realidad, hay que valorar un presupuesto aparte, para proceder a migrar el resto de empresas.

2.- No pactar la estrategia de implantación.

Si bien, en el apartado relativo al camino metodológico descrito en post anteriores, hemos desarrollado un conjunto de fases, objetivos y herramientas que juzgamos convenientes, es posible que los objetivos reales de la empresa  no concuerden con los vertidos en el citado camino y por lo tanto, haya que reconsiderar el conjunto de la estrategia de fases anteriormente descrita.

Para ilustrar con un ejemplo, es posible que  la empresa desde el principio quiera introducir los costes de albaranes procesándolos contra los pedidos, con lo que precise proceder a activar el plan de compras previamente para generarlos. O que, se pretenda introducir el detalle de las mediciones ejecutadas de producción, desde el comienzo.

En cualquiera de los casos, bien con el camino expresado en el presente documento o bien con el camino que necesite el cliente, hay que realizar una estrategia de implantación que esté acordada por ambas partes. Dicha estrategia debe de acordarse en un documento exprofeso o debe de estar contenida en algunos de los apartados dentro del DAF (Documento de Análisis Funcional de la implantación del ERP). La consideración más importante es que primero, antes que nada, con independencia de las variaciones que se quieran introducir sobre el camino descrito, se implante la contabilidad. A futuro, nos evitaremos, muchos problemas.

3.- Creer que no es necesario disponer de una Base de Datos propia de productos.

Este es un objetivo muy importante que algunas empresas constructoras lo han conseguido y otras todavía no. Obviamente aquellas compañías que subcontratan mayormente la obra, ese objetivo no tiene la importancia necesaria.

El conseguir tener una base de datos operativa de productos que nos posibiliten la consulta de precios primarios o descompuestos de unidades de obra, es un objetivo que agiliza enormemente el trabajo de asentar el coste previsto y el coste objetivo, tanto en la fase de estudios, como en la fase de ejecución, respectivamente. A menudo, a la hora de estudiar los costes de las unidades de obra no se descomponen sus costes y se hace una labor de estimación, lo que lleva después a ciertas sorpresas en su valoración.

Las bases de datos estándar (Guadalajara, GV, Itec, etc.) están más dirigidas para los proyectistas, que para las empresas de construcción, porque sus precios se mantienen cada vez que sale una nueva versión de ellas y por lo tanto, tienen escasa validez para estudiar los costes cotidianos.

La construcción de esta base de datos se debe de realizar partiendo de la adquisición de una base de datos estándar o de una codificación propia, a la cual le añadimos la experiencia comprobada en la ejecución histórica de las obras, a través de la integración de procesos del sistema de gestión de obras. Dicho de otra forma, si los productos generados en la B. D. se utilizan en todo el proceso de compras hasta su facturación, los precios se mantendrán actualizados permanentemente y entonces, la B. D. será totalmente útil para evaluar los costes de las obras.

Y no solo tiene importancia este hecho para calcular los costes. La importancia de la descomposición de costes en base a los precios primarios de las unidades de obra se pone de relieve en su ulterior utilización en la confección del plan de compras y en su proceso de adjudicación a proveedores.

4- Querer arrancar toda la solución en una sola fase

Cuando se confecciona el  DAF (Documento de Análisis Funcional de la implantación del ERP) se deben de describir todas y cada una de las adaptaciones previstas para que el aplicativo funcione debidamente en la instalación. El DAF debe de ser firmado por ambas partes y se entiende que una vez firmado, solamente lo reseñado es lo que se va a implementar.

La definición y el desarrollo de estas adaptaciones, frecuentemente es una fuente de conflictos que puede incluso llegar a  detener el proceso de implantación. Estos conflictos se producen por diversas circunstancias: falta de entendimiento de su definición , definición inexacta de la adaptación, desarrollo incorrecto por mala interpretación, escasez de recursos en el testeo o falta de testeo, falta de validación de los procesos por parte del cliente, etc..  A menudo, también ocurre, que la falta de tiempo, por la escasez de los recursos o por el empleo de recursos inadecuados o inexpertos, provoca muchos de los problemas citados.

También ocurre, que algunas adaptaciones son necesarias y no se han previsto en la fase previa, por lo que es necesario incluirlas en el DAF.

Una buena medida para resolver este problema es discernir aquellas adaptaciones de carácter sustantivo sin las cuales no podemos asegurar que la instalación se realiza con un mínimo de éxito, de aquellas de carácter supletorio o secundario. De esta forma nos aseguramos en un primer momento, la realización de un número menor de adaptaciones que además tienen un mayor impacto en la implantación. El desarrollo del resto, se aplaza para una segunda etapa, una vez que la instalación esté en marcha.

5- Creer que los usuarios se formaran sin una formación reglada

Otro aspecto donde hay que hacer hincapié es el que está relacionado con la formación de usuarios en los diversos módulos del aplicativo. A menudo esta formación se imparte sobre la marcha, sin reglarla con los cursos que sean necesarios, aislando en lo posible al personal de sus tareas habituales para que la formación sea aprovechada adecuadamente.

Una buena medida es que la formación a usuarios finales la imparta el propio personal del cliente, para lo cual la formación de usuarios clave y nuestra colaboración es vital.

También es conveniente con respecto a la formación a usuarios el clasificar a los mismos por las tareas que habitualmente realiza, ateniéndonos a sus funciones dentro de la compañía. En este sentido, la figura del jefe de obra, del administrativo de obra, del administrativo contable, son las figuras principales a las que debe ir dirigida la formación del conjunto de módulos de la solución. Es decir, al jefe de obra habrá que impartirle una formación diferenciada con relación a contenidos formativos, de las demás figuras.

En aquellas implantaciones donde puede ser conflictiva su ejecución por falta de personal asertivo, otra medida interesante es pilotar la formación con aquellos recursos (jefe de obra y administrativo de obra) que demuestren mayor entusiasmo por el proyecto y aplicar la formación y la ejecución íntegra de una obra, para que pueda ser un ejemplo, que por ósmosis se traslade al conjunto de los recursos del cliente.

6- Relegar el arranque del ERP ante cualquier circunstancia ajena al proyecto

Otro problema que se produce en el desarrollo de la implantación, es el que está relacionado con la interrupción del mismo, que viene justificado por problemas provocados por el cliente (falta de recursos, inconveniencia de plazos o dilatación de los mismos, etc) o porque no se está dirigiendo el proyecto adecuadamente por nuestra parte (problemas en el desarrollo de adaptaciones, empleo de recursos inadecuados, falta de dirección de proyecto, etc..).

Dichas interrupciones provocan, el desasosiego de los usuarios, el volver a empezar y a duplicar las tareas de formación y a perder la comba del proyecto.

En la medida de lo posible, es muy conveniente no interrumpir la implantación. Si se comienza una de las fases descritas de la estrategia acordada se debe de terminar con todas las tareas de la fase y arrancarla.

Si el problema viene provocado por el cliente, se deberá acordar y planificar cuando se reanudará la implantación, para asignar los mismos recursos que estaban interviniendo con anterioridad.

7- No documentar la implantación del ERP

Además del DAF, el proyecto debe de documentarse con relación al conjunto de comunicaciones (correo electrónico, actas de reunión, etc) que se realizan  a lo largo de su ciclo de vida.

Las reuniones establecidas con el cliente, sobre todo las reuniones de resolución, deben de elevarse un acta de reunión de cada una de ellas, señalando los aspectos más importantes que se hayan producido en el desarrollo de las mismas.

Con respecto a las comunicaciones de correo electrónico, deben de reclasificarse por proyecto, con de independencia de los actores de la comunicación.

Cuando surge un problema de interpretación en referencia a algún  determinado aspecto de la implantación o se provoca un conflicto en lo que debe de “caber” y no “caber” en su alcance, es preciso aportar toda la información que tengamos en nuestro poder, para poder argumentar y demostrar la justeza de nuestra argumentación. Sin ello, no podremos demostrarlo y difícilmente podremos negociar una salida beneficiosa.