*
Después de meses de esfuerzo llega el gran día: ¡la deseada puesta en marcha de nuestro nuevo sistema ERP! Pero, ¿Cuándo se debe autorizar la puesta en marcha y cuando no? ¿Cuáles son los aspectos más importantes y que requieren más atención? ¿Qué se debe esperar de los primeros días tras la puesta en marcha?
En este artículo abordaremos todas estas cuestiones para ayudar a celebrar muchas puestas en marcha.
La fecha de la puesta en marcha
Como cualquier otra fase del proyecto, para realizar una puesta en marcha exitosa hay que elegir bien la fecha o fechas durante la planificación del proyecto. Es una discusión que debe realizarse con calma y reflexión. Ya en la fase de iniciación se debe definir un período y una o dos alternativas. A medida que se progrese en la implementación se puede ir adaptando según las circunstancias. El plan debe ser definitivo antes de entrar en la última fase del proyecto: la puesta en marcha.
El sentido común aconseja un período donde se minimice el impacto potencial de los riesgos asociados a la misma. Por tanto, el momento más adecuado es cuando se produzca un valle en la actividad de nuestra empresa. Desafortunadamente este valle no es simultáneo entre departamentos, por lo que una buena planificación deberá buscar la mejor opción consensuada.
Lo mejor es definir un plan de transición más que un día concreto. Este plan detalla todas las actividades de migración y validación de datos y propone reuniones donde se decide la puesta en marcha de cada área y dentro de cada área, cada aplicación, cada interfaz y tipo de datos.
Muchas de las puestas en marcha de ERP que hemos vivido se han producido con el cambio de año. La principal razón siempre ha sido la facilidad de cerrar un ejercicio en un sistema y comenzar el nuevo año en el nuevo. También facilita la comunicación y quizás psicológicamente asumimos mejor los cambios con el año nuevo.
La autorización de la puesta en marcha
Independientemente que la puesta en marcha sea por fases o no, para cada decisión de poner en marcha el sistema se debe considerar lo siguiente:
- Los datos relevantes han sido validados por el negocio. Como se explicaba en el post “Validación de datos” este es un requisito indispensable. El negocio tiene que estar seguro de que los datos migrados al sistema son correctos.
- Las aplicaciones funcionan correctamente. Todos los componentes tanto estándar como específicos han sido testeados en los sistemas de prueba y no hay ningún defecto grave.
- Los usuarios han sido formados en procesos y sistema. La formación tanto en los nuevos procesos como en el manejo de la aplicación se ha realizado y los usuarios están suficientemente familiarizados con los cambios que se avecinan.
- Los riesgos han sido evaluados y existe plan B. Existe un listado de riesgos de lo que puede ir mal, han sido evaluados tanto en su probabilidad como gravedad, y las medidas para mitigarlos están implementadas. Estos riesgos incluyen defectos menores que han sido identificados, pero que no son indispensables para la puesta en marcha.
- El equipo de apoyo está disponible. Relacionado con el punto anterior, ante el riesgo de que algo vaya mal, lo mejor es disponer un equipo de apoyo definido, experto y de la dimensión adecuada. Debe haber diferentes niveles de apoyo, desde el más cercano a los usuarios y que pueda discernir si un problema es del usuario o de la aplicación, hasta el más experto que pueda comunicar a nivel técnico con los proveedores del sistema ERP. En muchos casos este equipo suele ser distinto del equipo de proyecto por lo que se debe asegurar una colaboración adecuada entre ambos y un buen traspaso de información.
- Toda la información ha sido comunicada y asimilada por la organización. Toda la información relevante (resultados de las validaciones, tests, riesgos, fechas de puesta en marcha de cada uno de los módulos, quién es el equipo de apoyo y medios de contacto, cómo acceder al nuevo sistema y al viejo sistema, etc., etc.) se ha comunicado según el plan de comunicación y existe alguna evidencia de que ha sido asimilada por la organización.
Si todos estos puntos están completados el comité de dirección debe dar luz verde a la puesta en marcha. ¡Enhorabuena!
La fase de estabilización
Los días posteriores a la puesta en marcha suelen ser de relativa tranquilidad. El sistema funciona relativamente bien y no existen grandes problemas. Existen varias razones para explicar este fenómeno.
- La actividad de los usuarios es menor de lo habitual. Es normal que los usuarios tengan un cierto respeto al nuevo sistema. Necesitan tiempo para habituarse, para aclarar sus dudas e incluso para acceder al sistema. Al principio es común que haya problemas de contraseñas, sobre todo si son usuarios que han entrado en un sistema de formación. Intentan acceder al sistema final con la contraseña del sistema de pruebas, bloquean su cuenta, etc.
- La actividad del sistema es menor. También este sistema ERP está a menor rendimiento ya que la puesta en marcha se debe diseñar de esa manera. Es la medida más fácil de implementar, de asegurarse que el sistema funciona bien.
- Los errores tardan más tiempo en detectarse. No es normal que haya errores de aplicación catastróficos en el sistema si se ha hecho un testeo de calidad, pero siempre va a haber algún tipo de error. Escenarios raros o no contemplados, operaciones poco frecuentes pueden traer resultados inesperados. Precisamente por su naturaleza, es raro que este tipo de problemas se produzcan en los primeros días. Para considerar el proyecto un éxito se debe esperar unas semanas hasta que el sistema se estabilice. El volumen de actividad debe ser equivalente al del viejo sistema, se debe asegurar de que al menos el cierre contable de un mes se ha llevado a cabo y que todas las funcionalidades se han ejecutado al menos una vez en el sistema real.
Durante esta fase de estabilización el equipo del proyecto debe:
- Monitorizar activamente el sistema. De este modo se asegura que todo funciona correctamente y comprueba que los usuarios están utilizando el nuevo ERP de una manera uniforme entre áreas de negocio y áreas regionales. También sirve para resolver problemas antes de que los usuarios los detecten o sean demasiado grandes.
- Resolver problemas. Ya sean pequeños defectos identificados con anterioridad o nuevos problemas, el equipo debe trabajar con el equipo de apoyo para resolverlos lo antes posible.
- Dar formación. Si durante la monitorización se detectan carencias en la formación, el equipo debe dar sesiones adicionales.
- Como en el resto de las fases del proyecto comunicar bien es fundamental. Informar de donde están las respuestas a las dudas más frecuentes, a la documentación necesaria, listas de errores detectados y su estado. Una comunicación de buena calidad y transparente siempre ayuda a generar confianza.
Conclusión
La puesta en marcha es la fase donde el nuevo sistema ERP comienza a funcionar en producción. Para garantizar su éxito se debe haber elegido el período y las fechas de comienzo de actividad de una manera lógica y adaptada a la actividad de la empresa.
La autorización de la puesta en marcha debe ser predecible. Si se cumplen unos criterios acordados durante la planificación (los datos son correctos, las aplicaciones funcionan correctamente, los usuarios están formados, los riesgos evaluados y la comunicación ejecutada), se debe autorizar y si no es así no. Un plan B tiene que estar siempre disponible como alternativa.
Una vez el sistema esta en funcionamiento tarda cierto tiempo en estabilizarse. No se debe bajar la guardia hasta que todas sus funcionalidades hayan funcionado en el sistema final (no el de pruebas).
Si te ha interesado este POST te invitamos a que leas también:
- ¿ QUÉ ES UN ERP ? EL SISTEMA DE GESTIÓN INTEGRAL POR EXCELENCIA
- IMPLEMENTACIÓN DEL ERP - LA INICIACIÓN DEL PROYECTO
y si quieres conocer una herramienta de ERP:
*Photo by rawpixel.com from Pexels