Y llega un momento que la implantación no avanza, ya bien sea por problemas de la base o que las reuniones de requisitos, las pruebas, las personas siempre se encuentran girando con respecto a un tema. Si te encuentras aquí puedes estar ante el síndrome del sistema «perfecto», es decir, todo parece paralizado porque bien sea un módulo, un flujo, un desarrollo o todo a a la vez no termina de cerrarse porque se intenta perfeccionar continuamente, sin fin.
Cuáles son los síntomas que nos indican que nos encontramos ante lo que quiere ser un ERP «perfecto»:
– A nivel de interfaz está lleno de controles y validaciones para que el usuario no se pueda equivocar. El equipo de desarrollo dedica más tiempo a esto que a lo que de verdad importa, crear un core fiable y rápido.
– Cantidad de informes que para el usuario no son prioritarios. Todos ya sabemos que cuando abres la puerta de los informes ya no puedes volver a cerrarla y se empiezan a «colar» reportes de todo tipo. El equipo de desarrollo invierte la mayoría de tiempo haciendo estas vistas sobre la base de datos y cuya dificultad estriba en la parte gráfica del mismo. Además hay que recordar que cada informe que se desarrolle después hay que mantenerlo.Existen en los ERP’s actuales aplicaciones de reporting integrada que permiten al usuario autonomía para explotar la información.
– Muchas automatizaciones, funcionalidad de modificaciones masivas y «botones rojos» que intentan hacer la vida más fácil pero que raramente se utilizan y son difíciles de implementar al intentar cubrir tanta casuística distinta
– Interfaces muy elaboradas con múltiples entidades maestro- detalle que hacen muy complicada la programación que corre por debajo.
En que debería haberse invertido este tiempo en vez de ir diseñando un ERP «perfecto»
– Adaptar las peticiones al estándar lo máximo posible. El estándar existe porque funciona fiablemente. Cuanto más nos alejemos de él más problemas aparecerán.
-Analizar para llegar a diferenciar que requerimientos son esenciales y cuáles pueden esperar a una siguiente fase.
-Entregar a los key users prototipos para que los pueda ir probando y obtener feedback.
-Probar, probar y probar. Siempre teniendo en cuenta que esos tester no sean los propios programadores pues inconscientemente siempre prueban lo mismo y no tienen toda la casuística del negocio.
Mis recomendaciones:
- Detectar a los usuarios que bloquean el avance porque quieren que se diseñe hasta el mínimo detalle como si no se fuera a hacer nada más en su parte después. Negociar con ellos.
- Intentar no alejarse mucho del estándar y evitar grandes desarrollos por lo menos al principio.
- Ser conscientes que el usuario con la formación suficiente no tiene porque introducir valores erróneos. Evitar filtros y controles excesivos
- Ceñirse a la planificación estableciendo fechas de entrega razonables. Si no hay una fecha prevista para cada hito, no hay proyecto, ni compromiso, ni dirección.
Finalizando: «No digo que no haya que buscar un ERP perfecto, lo que quiero hacer hincapié es que esto debe ser el fin y no el camino que nos lleva a comprometer las entregas».
Muy buenas observaciones. Se suele caer en la «perfeccion». Y al final no se avanza.