Proceso de cutover de ERP (del ensayo al hypercare)
Flujo editable del cutover de un ERP para puestas en marcha de SAP, Oracle, Dynamics 365 o NetSuite: cutover simulado, congelación del sistema heredado, carga de datos, conciliación, decisión go/no-go, marcha atrás y salida del hypercare.
¿Qué es proceso de cutover de ERP (del ensayo al hypercare)?
Un plan de cutover suele ser una hoja de cálculo de varios cientos de tareas, y debe serlo, porque el detalle importa. Lo que la hoja no muestra bien es la forma del fin de semana: las puertas en las que el trabajo se detiene hasta que alguien firma y los caminos que se activan cuando una puerta falla. Eso es lo que el comité de dirección necesita entender antes de la puesta en marcha y lo que el equipo debe haber ensayado.
Esta plantilla dibuja esa forma. Un cutover simulado que puede fallar y volver atrás. Una conciliación que el negocio tiene que firmar. Una decisión go/no-go con criterios acordados de antemano y un camino de marcha atrás que termina en una puesta en marcha aplazada y no en una carrera a ciegas. Después, el hypercare con criterios de salida, de modo que termine por evidencias y no por una fecha.
Sirve para cualquier ERP, sea SAP S/4HANA, Oracle Fusion, Dynamics 365, NetSuite o un sistema más pequeño. Renombre los carriles con los roles de su proyecto, mantenga el runbook detallado en su plan de proyecto y use este flujo para explicar y aprobar las puertas.
Qué cubre este diagrama de flujo
En esta plantilla
- La línea base del runbook de cutover y uno o más cutovers simulados con objetivos de tiempo y de defectos
- Congelación de transacciones y datos maestros en el sistema heredado
- Extracción de los saldos finales y las partidas abiertas, carga de datos maestros y transacciones y cutover técnico de interfaces y trabajos
- Conciliación por el negocio de los datos cargados, con un camino de recarga cuando se detectan diferencias
- La decisión go/no-go, el plan de marcha atrás, la apertura del sistema nuevo y los criterios de salida del hypercare
Cuándo usar esta plantilla
- Planifica la puesta en marcha de una implantación de ERP y necesita que el comité de dirección apruebe las puertas
- El plan de cutover existe como lista de tareas y nadie sabe explicar los puntos de decisión
- Una puesta en marcha anterior no tenía criterios de marcha atrás acordados y quiere definirlos de antemano
- Ejecuta un despliegue por fases y necesita un patrón de cutover repetible para cada país o sede
Cómo funciona
Renombre los carriles con los roles de su proyecto
Asigne los carriles al responsable del cutover, los usuarios clave de negocio, el equipo de migración de datos, los equipos técnicos y el comité de dirección o de puesta en marcha.
Escriba sus criterios go/no-go
Ponga los criterios acordados en la nota de la decisión: conciliación firmada, ningún defecto de severidad 1 abierto, soporte cubierto y marcha atrás aún posible.
Fije los objetivos del ensayo
Escriba los objetivos de tiempo y de defectos en la decisión del cutover simulado y planifique al menos dos ensayos para una puesta en marcha grande.
Enlace el runbook detallado
Adjunte o enlace el runbook a nivel de tarea en los pasos correspondientes para que el flujo siga siendo legible y el detalle quede en un solo lugar.
Apruebe el plan
Envíe el flujo a aprobación al patrocinador del programa y a los propietarios de procesos; la versión aprobada es su registro de lo acordado.
Preguntas frecuentes
¿Qué es un plan de cutover de ERP?
Es el plan detallado para pasar del sistema heredado al nuevo ERP: congelar el sistema antiguo, cargar los datos finales, cambiar las interfaces y los usuarios y confirmar que el sistema nuevo es correcto antes de que la gente empiece a trabajar en él. Incluye responsables, plazos, dependencias, puntos de firma y un plan de marcha atrás.
¿Qué deben incluir los criterios go/no-go?
Los criterios habituales son la conciliación de datos firmada por el negocio, ningún defecto de severidad 1 abierto y una lista acordada de problemas conocidos de severidad 2, usuarios formados, soporte y hypercare cubiertos, interfaces probadas de extremo a extremo y la confirmación de que la marcha atrás sigue siendo posible dentro de la ventana del cutover.
¿Cuántos cutovers simulados conviene ejecutar?
Al menos un ensayo completo con datos similares a los de producción y el runbook real, y normalmente dos o tres en una implantación grande. Cada ensayo debe cronometrarse y medirse frente a los objetivos, y el runbook debe actualizarse antes del siguiente.
¿Cuándo termina el hypercare?
Cuando se cumplen los criterios de salida acordados, no en una fecha fija. Los criterios habituales son un volumen de tickets a la baja, ningún problema de severidad 1 abierto y el primer cierre de mes completado en el sistema nuevo.
Dónde encaja este proceso
En la mayoría de las organizaciones, este proceso sigue a Proceso de implementación de software empresarial.
Viene antes
- Proceso de implementación de software empresarial — Plantilla para descubrimiento, requisitos, diseño, configuración, integración, migración, pruebas, UAT, puesta en marcha, soporte intensivo y traspaso.
- Proceso de migración de SAP ECC a S/4HANA — Flujo editable de migración de SAP ECC a S/4HANA: Readiness Check, análisis de código personalizado, fit-to-standard, decisión entre brownfield, greenfield o transición selectiva de datos, pruebas y cutover de conversión.
- Proceso de actualización de Dynamics AX 2012 a Dynamics 365 — Flujo editable de actualización de Dynamics AX 2012 a Dynamics 365 Finance y SCM: análisis en Lifecycle Services, decisión entre actualizar o reimplantar, código a extensiones, actualización de datos, UAT y puesta en marcha.