Entornos implantación y soporte ERP

Abundando un poco sobre el artículo de hace unas semanas ‘Entornos y metodologías de desarrollo en el software de gestión’, podríamos decir que si existen dos entornos imprescindibles en una implantación y soporte de un ERP son el de pre-producción y el de producción.

 

Con el entorno de pre-producción se pone a prueba el sistema en condiciones similares a como será en producción, usándose para realizar la formación de los usuarios, las migraciones y el testeo del grado de fiabilidad de éstas, la detección de errores, la reproducción de errores del entorno de producción, las pruebas y simulaciones de los usuarios, el testeo de nuevos módulos implementados, etc. Aquí por tanto, el entorno de pre-producción tendría características de pruebas también.

El entorno de producción es evidente, pues es el entorno donde realmente van a trabajar los usuarios y donde no ha lugar para pruebas, ensayos ni simulaciones. Es el core transaccional de la empresa, así que no se puede someter a ningún proceso dudoso o de riesgo.

Como la economía no es muy boyante últimamente, tampoco debe sorprendernos que el entorno de pre-producción y el de producción se encuentren en las mismas máquinas, aunque eso sí, lo más aislados posibles. (Nota: Ya, ya sé que no es lo idóneo, pero que levante la mano quien tenga clientes perfectos y que lo entiendan)

Fuera de los imprescindibles, nos encontramos otros dos entornos que se harán necesarios en función de las necesidades de la empresa a implantar. Para la implantación de un ERP con pocas transacciones y sin desarrollos personalizados, el entorno de desarrollo y el entorno de pruebas (como tal y separado) son innecesarios. A medida que haya una mayor carga de desarrollos o mayor criticidad en la aplicación, éstos entornos van adquiriendo mayor relevancia.

Sin embargo, la experiencia me dice que no hay cliente fácil, y siempre, durante la implantación surgen cuestiones, a pesar que no se hayan detectado en fases previas, que requieren nuevas configuraciones o nuevas funcionalidades que permitirán al cliente ser más operativo y ágil en su día a día con el ERP. Algunas de ellas podremos convencer al cliente que se incluirán en el roadmap del producto para futuras versiones, pero otras no serán tan bien acogidas, así que inevitablemente será necesario un entorno de desarrollo y uno de pruebas, aunque sea a muy pequeña escala.

El que un ERP vaya a tener pocas transacciones no debería ser el factor decisivo a la hora de dilucidar sobre los distintos entornos para la realización de la implantación y soporte. Podemos encontrarnos con sectores donde el número de transacciones sean muy bajas pero tengan un carácter estratégico o crítico para el cliente (defensa,  sanidad, seguridad, etc.), y por el contrario, podemos encontrarnos con clientes con un volumen transaccional muy alto y cuya criticidad es puramente operativa, pero no funcional. En ambos casos, sería conveniente un entorno de pruebas idéntico (o lo más similar posible) al entorno de producción real.

El hecho de los desarrollos personalizados sí deberían exigir el «montaje» de un entorno de desarrollo y otro de pruebas de forma imprescindible, con el fin de realizar los nuevos módulos, aislándolos de los entornos de pre-producción y producción hasta el cumplimiento de unos estándares de calidad.

A modo de resumen. A mayor verticalización, menor desarrollo, y por tanto, menor número de entornos necesarios. A mayor necesidad de esos desarrollos, lo que suele darse en productos muy horizontales o en los desarrollos a medida, el número de entornos requiere ir incrementándose.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email