Hace unos días rememoraba con un cliente como la implicación del proveedor en la implantación del ERP puede ser la diferencia entre el fracaso o el éxito del proyecto. Ambos recordábamos esta época como uno de los períodos más duros y complicados que pasamos en muchos años, ellos como sufridores y nosotros como responsables de un proyecto que no podía fracasar.
El cliente no era nuevo, sino que provenía de un desarrollo a medida nuestro en una tecnología ya obsoleta y que había ido evolucionando de una forma demasiado rápida e incoherente, por lo que la solución no pasaba por la evolución de su sistema legacy, sino que era conveniente la migración a nuestra solución ERP DProduction orientada al sector de la manufactura, principalmente en el sector de la tapicería, descanso y muebles.
Si bien la solución cubría en un elevado porcentaje sus necesidades, quedaba un porcentaje que había que analizar, diseñar y desarrollar para conseguir una mejora cualitativa y cuantitativa de sus procesos. Recuerdo esa fase de preparación del análisis diferencial y check list de requerimientos con un especial interés. Era para nosotros un cliente de muchos años y emblemático en su sector, y además, una gran referencia. Había que hacerlo bien y no dejar cabos sueltos.
Tras mucho trabajo de preparación, se planificó las primeras reuniones con el jefe del proyecto y los key users y posteriores reuniones con los usuarios, para lo cual se les exigió que realizaran su lista de requisitos, así como necesidades de primer nivel y otras menos prioritarias. Se solicitó a los usuarios que realizaran una labor de «limpieza» de datos maestros para no trasladar vicios y malas herencias al nuevo sistema en el proceso de migración.
El ERP de fabricación DProduction.erp para el sector de la tapicería, descanso y muebles.
Tras el relevo del jefe del proyecto por falta de tiempo y asignación de otro responsable, el proceso se dilató y sin apenas avances significativos al proyecto. Toda la documentación preparada tras semanas y semanas de trabajo, no llegó a leerse prácticamente por nadie (excepto algún caso aislado), la formación se redujo a tres sesiones en total de un par de horas y el proyecto comenzó a dilatarse más en el tiempo.
Finalmente se ordenó desde la dirección de la empresa un arranque big bang en una fecha determinada. Se decidió que no hubiera más formación ni reuniones y que se procediera directamente al arranque en la fecha solicitada. Les avisé del problema que se ocasionaría, pues si bien el ERP podría cubrir muchos de los procesos existentes, otros diseñados a medida durante años quedarían fuera y sin control, así como otros, si bien existentes, distaban mucho de la forma de trabajar del cliente.
A pesar de ello, gran parte de la parametrización y configuración del ERP se había hecho. Los formatos se habían diseñado y eran funcionales. Algunas de los procesos que yo había entedido estratégicos en su empresa se habían desarrollado, pero no habían pasado ningún filtro de testeo por parte del cliente. La migración se realizó tal cual, sin filtros y heredando viejos problemas…
Sin embargo, el arranque fue un auténtico desastre. Los usuarios se encontraban muy nerviosos por la falta de formación y el desconocimiento ante la herramienta, no solo funcionalmente hablando sino también desde el punto de vista operativo (no conocían ni las teclas básicas para funcionar). Además, el hecho de no haberles hecho partícipes del proyecto, les enfadaba aun más. Terminaron llevando las quejas a gerencia y la situación cada vez era más complicada.
Por nuestra parte estábamos dedicando todos los recursos necesarios para sacar el proyecto del agujero en que se encontraba. Personalmente mi involucramiento era máximo desde el punto de vista técnico, pero también desde el punto de vista comercial, todos los días tenía que «poner la cara». Tenía 3 desarrolladores al 100% y yo personalmente al 150%, así que se dedicaba más tiempo a apagar fuegos que a avanzar en el proyecto.
Tras hablar en varias ocasiones con gerencia, finalmente entendieron que nuestra apuesta por su proyecto era máxima. Era obvio que nuestra disponibilidad con ellos y las ganas de sacar adelante el proyecto era nuestro único objetivo, independientemente del coste económico que nos estaba suponiendo. Llegar a estabilizar el proyecto nos costó al menos 4 meses, pero finalmente se llegó a un punto donde prácticamente todas las prioridades quedaron cubiertas. Cubrir el resto de las necesidades, que solo fueron detectándose mediante un proceso iterativo con los usuarios en producción, nos llevó prácticamente un año, aunque ya con menos recursos humanos necesarios.
Pienso que hoy es un cliente muy estable, y aunque siempre están «enfrascados» en nuevos requerimientos, los desarrollos se van escalonando de una forma paulatina y coherente. Son nuevos proyectos, algunos incluso de gran calado, pero con un análisis previo por parte de los key users muy importante. Al final han sido conscientes de que los cambios deben liderarse desde dentro por los propios usuarios clave y que los mayores beneficiados son ellos, así que todo se estudia con mayor nivel de detalle.
Conozco algunos casos donde el proyecto se ha torcido tras el arranque debido al elevado coste personal de los implicados, y por supuesto, del coste económico. No todas las empresas consultoras o implantadoras son capaces de soportar esta presión y de disponer los recursos necesarios para no permitir el fracaso en la implantación del ERP. Esto, por supuesto, sin desmerecer en absoluto la apuesta del cliente por el proveedor y seguir confiando en él, a pesar de las dificultades.
|
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|
