Cimatic

Lista de verificación de preparación para la puesta en marcha de ERP

Después de muchos meses de meticulosa planificación, construcción y pruebas, puede llegar a un punto en el que piense: ‘¡Estamos listos para que su ERP comience a funcionar!’

Si bien es fácil quedar atrapado en la emoción de completar hitos importantes, es importante estar completamente preparado antes de accionar el interruptor.

Recomendamos utilizar una lista de verificación de preparación de puesta en marcha de ERP para ayudarlo a decidir si su empresa está realmente lista para la puesta en marcha. Si bien la siguiente lista de verificación no es exhaustiva, cubre los aspectos técnicos de la preparación para la puesta en marcha:

Lista de verificación de puesta en marcha de ERP:

1. Todos los casos de prueba son ejecutados y aprobados

Hay una razón por la cual los planes de proyectos ERP contienen varias iteraciones y tipos de pruebas. Las pruebas unitarias, las pruebas de procesos, las pruebas de integración de sistemas y las pruebas de aceptación del usuario están diseñadas para garantizar que sus personalizaciones, configuraciones e integraciones estén listas para la producción. Tener una tasa de aprobación alta en todas estas pruebas es un buen indicador de que puede estar listo para la puesta en marcha.

Lo importante no es solo la cantidad de casos de prueba aprobados, sino también la calidad y la cobertura. Para las pruebas unitarias, generalmente un consultor o desarrollador de ERP puede crear los casos de prueba, pero para los otros tipos de pruebas, la empresa debe aprobar los casos de prueba. Esto garantiza que no surjan escenarios sorprendentes después de que los usuarios finales tengan en sus manos el nuevo sistema ERP.

2. No hay errores de gravedad 1 o 2 restantes pendientes

Si su equipo decide esperar hasta que se solucionen todos los errores inferiores a la gravedad 2, nunca se activará. Está bien si todavía tiene algunos errores persistentes, siempre que no sean de gravedad 1 (showtopper) o de gravedad 2 (alto impacto comercial). Incluso si existen soluciones alternativas para continuar ejecutando procesos comerciales, dejar un error de gravedad 1 o 2 en la producción puede crear un desorden de datos.

Por ejemplo, imaginemos que existe un error de gravedad 2 para avisos de envío avanzados (ASN). En este caso, un probador de control de calidad se da cuenta de que algunos ASN están siendo rechazados y no están llegando al sistema ERP. Como resultado, se recomienda una solución alternativa para monitorear la cola de los ASN rechazados y desencadenar un reenvío de las fallas.

Incluso si esta solución permite que se importen los ASN, el problema real podría ser que el retraso en el procesamiento de estos ASN está causando que la fecha de recibo financiero se retrase un día o más. Al final del mes o trimestre, esto podría crear un desastre para el equipo de finanzas.

Dicho esto, debe tener un plan para abordar cualquier error de gravedad 1 o 2 que surja cerca de su fecha de lanzamiento. Sin un plan de mitigación para este tipo de errores de última hora, corre el riesgo de retrasar significativamente su fecha de lanzamiento.

3. La migración de datos y las actividades de corte que se han practicado

En el teatro, una producción nunca se sumerge en la noche de estreno sin unos pocos ensayos. Estas son prácticas comunes porque ayudan a los actores a sentirse cómodos con sus líneas mientras se visten con vestuario e iluminación completa. Durante un ensayo general, los problemas pueden volverse evidentes, lo que brinda a los directores la oportunidad de abordar los problemas mientras aún hay tiempo.

Practicar la migración de datos ERP y las actividades de transición en un entorno de preproducción es como un ensayo general. Los actores son su equipo de proyecto, las líneas son los procesos de negocios y los trajes y la iluminación son los datos de producción y el entorno.

Mientras practica la migración de datos, puede encontrar datos corruptos o duplicados que, si se hubieran importado directamente a la producción, habrían contaminado el entorno prístino.

4. Los datos de producción están preparados y listos para migrar

Los datos no siempre juegan bien. Incluso si ha practicado la migración del legado al nuevo software ERP varias veces, es mejor no esperar hasta la noche anterior a la puesta en marcha para realizar la migración real.

Recomendamos definir una fecha y hora de corte para cuando las transacciones heredadas ya no se considerarán para la migración. Cualquier transacción nueva más allá de la fecha límite puede migrarse en una ola separada.

5. Su entorno de producción está listo

Parece una obviedad, pero se sorprenderá de cuántas definiciones diferentes de ‘listo’ encontrará entre un equipo de proyecto.

La mejor definición de ‘listo’ es: la infraestructura para el entorno de producción está en su lugar y ajustada al máximo rendimiento. Esto significa que las configuraciones están habilitadas, los usuarios están cargados y los roles de seguridad están activados. También significa que los puntos de integración se definen y se verifican las respuestas.

En algunos casos, ‘listo’ también puede implicar la compra y configuración de cualquier hardware requerido, como impresoras, escáneres, balanzas, registros o lectores de pagos.

6. La estrategia de lanzamiento está definida, programada y comunicada

Para implementaciones por fases, el cronograma debe comunicarse a las unidades de negocios afectadas. Nunca debería sorprender a los usuarios cuando ya no pueden acceder a sus herramientas heredadas.

Por ejemplo, imagine que es un minorista con cien tiendas en cuatro zonas horarias. El cronograma para la primera fase de su implementación podría tener este aspecto: las tiendas de la Costa Este reciben hardware nuevo el sábado por la noche, el hardware se configura e instala el domingo por la noche y el lunes por la mañana están en vivo con el nuevo software. Luego, después de una semana en producción, los comentarios se recopilan y analizan antes de la siguiente fase.

Si sus tiendas de la costa este están al tanto de este horario, estarán más preparadas para la puesta en marcha.

7. El equipo de soporte está preparado

Cuando surjan incidentes (y lo harán), necesitará un equipo de soporte equipado con todos los recursos necesarios. Este equipo debe tener acceso a expertos en ERP, analistas de negocios, especialistas en procesos y defensores de la gestión del cambio. Esto garantiza que cualquier ticket que llegue a través de la mesa de ayuda se pueda abordar sin problemas para encontrar el recurso adecuado.

El proceso para crear y administrar tickets entrantes también es importante para definir antes de la puesta en marcha. No desea que se agregue estrés durante la publicación, ya que este es un momento muy ocupado.

 

Me interesa saber más