Preparación para la puesta en marcha del ERP: las evidencias necesarias para autorizarla

Imagine una reunión de revisión en la que el equipo de implantación comunica que ha terminado el trabajo, pero un responsable de proceso no puede confirmar que los usuarios sepan gestionar las excepciones y el partner no ha confirmado quién dará soporte a la operación en producción. El patrocinador del proyecto no debería interpretar la finalización de la entrega como una autorización para empezar a operar.

Autorice la puesta en marcha del ERP cuando los responsables de negocio puedan demostrar que están preparados para operar y el equipo de soporte pueda asumir la responsabilidad sobre los riesgos pendientes. Aplácela cuando un proceso crítico dependa de usuarios sin preparar, especialistas no disponibles o una vía de escalado sin probar. La aprobación condicionada solo tiene cabida entre esas opciones cuando sus condiciones son explícitas y exigibles.

Esta lista de comprobación de preparación para la puesta en marcha del ERP aborda la autorización para entrar en producción. Complementa, pero no sustituye, la aprobación técnica de la transición, la conciliación de datos y la planificación de la recuperación. También es posterior a la decisión de mejorar o sustituir el ERP: ahora se trata de determinar si la organización puede operar con la versión que se está entregando.

Separe la aceptación del responsable de proceso de la finalización de la entrega

Pida a cada responsable de un proceso crítico que presente una declaración de aceptación sobre el alcance real de la versión. Debe identificar los flujos de trabajo revisados, los usuarios que han participado, las limitaciones pendientes y cualquier procedimiento alternativo que el responsable esté dispuesto a utilizar. El informe del director del proyecto que confirma la finalización de las pruebas debe servir de base para esta declaración, no sustituirla.

La diferencia está en la responsabilidad. Un consultor funcional puede explicar cómo funciona el proceso configurado; el responsable de negocio debe decidir si el procedimiento operativo propuesto es aceptable. Exija ambas perspectivas cuando el negocio dependa de un traspaso entre equipos.

Por ejemplo, en una revisión hipotética de gestión de pedidos, pida a los usuarios que demuestren el flujo de trabajo habitual y una excepción que requiera intervención. Después, pregunte quién detecta la excepción, quién autoriza la respuesta y quién confirma que el trabajo puede reanudarse. Es un ejercicio de aceptación operativa, no una prueba completa de integración o conciliación.

Registre los desacuerdos en lugar de convertirlos en un estado verde. Si un responsable de proceso no puede aceptar el flujo de trabajo, determine si el obstáculo es la falta de preparación, un defecto sin resolver o un procedimiento operativo inaceptable. La siguiente acción debe abordar ese obstáculo concreto. Otra demostración del equipo de implantación no es la respuesta si lo que falta es acreditar la capacidad de los usuarios.

Compruebe la preparación de los usuarios, no solo su asistencia a la formación

El profesional de ERP Francesco Perrotta señala que, en su experiencia, subestimar la formación es un problema recurrente y lo relaciona con un uso ineficaz del sistema y una reducción de los beneficios de la implantación. La consecuencia práctica para la aprobación es clara: pida evidencias de que los usuarios pueden realizar su trabajo, no solo de que se ha impartido formación.

Pida al responsable de formación que relacione los roles afectados con las tareas que deberán realizar en el arranque. Revise la asistencia junto con las prácticas observadas, las dudas pendientes, las sesiones de recuperación previstas y el acceso a instrucciones actualizadas. Incluya a los suplentes y a los usuarios ajenos al grupo principal del proyecto. Un usuario clave bien preparado no debe utilizarse como representación de todo un equipo operativo.

La evidencia más sólida es una demostración de las tareas por parte de las personas que deberán ejecutarlas, utilizando el procedimiento y los permisos previstos para producción. Pídales que expliquen cuándo se detendrían, solicitarían una autorización o abrirían una solicitud de soporte. Una presentación y un registro de asistencia siguen siendo documentos útiles, pero no responden a esas preguntas.

Establezca criterios de aceptación en función de las consecuencias de un fallo en cada rol. Para una tarea crítica, exija que el responsable del proceso identifique la carencia de preparación pendiente y su consecuencia operativa. Si los usuarios necesitan acompañamiento, asigne esa tarea y verifique el resultado antes de aprobar. Si se propone un procedimiento alternativo, compruebe que quienes lo ejecutarán conocen sus límites y que su responsable acepta la carga de trabajo adicional.

Confirme la capacidad de soporte y ensaye el escalado

Perrotta también advierte de que algunos partners tienen problemas de asignación de personal porque acumulan demasiados proyectos, lo que deja a los clientes sin la persona que necesitan cuando requieren soporte. Esto no justifica descartar a un partner por su tamaño. Sí justifica verificar la disponibilidad real en el momento de autorizar la puesta en marcha.

Solicite un cuadro de cobertura del soporte con los nombres de los contactos internos y del partner, sus responsabilidades, los periodos de cobertura y sus suplentes. Pida a los responsables de área que confirmen que los especialistas internos tienen tiempo reservado para soporte, además de sus funciones habituales. Pida al partner que identifique a las personas funcionales y técnicas que cubrirán esta puesta en marcha, en lugar de aceptar una garantía genérica de que existe un equipo de soporte.

Si la propuesta original no deja claras esas responsabilidades, retome las comprobaciones de equipo y disponibilidad utilizadas para seleccionar al partner. En la puesta en marcha ya no se trata de la capacidad general del proveedor, sino de si las personas necesarias pueden responder para este alcance operativo.

Ensaye el escalado con una interrupción hipotética del negocio. Haga que un usuario comunique el problema, que el centro de soporte lo derive y que los especialistas responsables expliquen sus siguientes pasos. Confirme quién evalúa el impacto en el negocio, quién autoriza un procedimiento alternativo y quién se comunica con las áreas operativas afectadas. No equipare la asignación de una incidencia con la responsabilidad de recuperar la operación.

Para el traspaso, pida al responsable del equipo receptor de soporte que acepte los procedimientos, los accesos, el registro de problemas conocidos y los contactos de escalado. Un correo que indique que se ha enviado la documentación ofrece menos garantías que la confirmación de que el equipo receptor puede utilizarla. Si sigue habiendo desacuerdo sobre las responsabilidades, resuélvalo antes de pedir al patrocinador que acepte el riesgo.

Reserve capacidad para la estabilización y las actualizaciones posteriores

Defina la estabilización como un trabajo con responsables que rindan cuentas, no simplemente como un periodo en el calendario del proyecto. Identifique quién clasificará y priorizará las incidencias de producción, acompañará a los usuarios, aprobará cambios y mantendrá las instrucciones operativas. Separe el trabajo urgente de recuperación de las solicitudes de mejora para no comprometer implícitamente a las mismas personas con ambas tareas sin establecer prioridades.

La responsabilidad continuada también se extiende más allá de la versión inicial. En una conversación de la comunidad de Microsoft Dynamics, Steve Goodwin describió las conversaciones necesarias para ayudar a la alta dirección a comprender el proceso de actualización de la plataforma, la gestión de características y las capacidades disponibles para su organización. Es el relato de un cliente en un contexto específico, no una prueba de un resultado típico en proyectos ERP.

La conclusión útil es que la comprensión de la dirección debe abarcar lo que ocurre después del arranque. Pregunte quién revisará las actualizaciones relevantes, evaluará su impacto en el negocio, coordinará las pruebas y preparará a los usuarios para los cambios aceptados. Reserve capacidad para esas responsabilidades en lugar de asumir que terminar la implantación también pone fin a la necesidad de participación del negocio.

Acuerde qué evidencias permitirán pasar del soporte intensivo de estabilización a la operación habitual. Conviene comprobar si las incidencias críticas tienen una resolución o un tratamiento aceptados, si la asignación de responsabilidades de soporte está funcionando y si los responsables de proceso pueden gestionar la carga de trabajo restante. Elija criterios adecuados para la versión; no sustituya una decisión de aceptación por el simple transcurso de un periodo arbitrario.

Incluya responsables identificados y riesgos pendientes en el registro de decisión

Utilice la siguiente hoja de trabajo como ayuda para la decisión del patrocinador. Sustituya los roles por nombres concretos, enlace las evidencias e indique la exposición al riesgo pendiente. No convierta las filas en una puntuación que permita diluir una carencia operativa grave dentro de una media.

La plantilla de decisión sobre la preparación para la puesta en marcha ofrece un mecanismo de registro útil: la aprobación condicionada recoge la condición, el responsable, el plazo, la persona que verificará su cumplimiento y la consecuencia de no cumplirla. Utilice ese mecanismo para distinguir una autorización verdaderamente condicionada de una promesa informal de terminar más adelante.

Apruebe cuando las evidencias respalden la operación en producción y los riesgos restantes tengan una aceptación con responsables identificados. Utilice condiciones para carencias acotadas cuya subsanación pueda verificarse antes de que comience la actividad afectada. Aplace cuando una responsabilidad operativa crítica siga sin respaldo. Registre el motivo, la acción correctiva y las evidencias necesarias para la siguiente decisión, no solo una nueva fecha.

Antes de la reunión de aprobación, pida a cada responsable de proceso crítico y al responsable del equipo receptor de soporte que incorporen sus evidencias y riesgos pendientes al mismo registro de decisión. Si necesita capacidad funcional o técnica para subsanar esas carencias, hable con los especialistas ERP de Digiventi sobre el alcance de la puesta en marcha y las responsabilidades de soporte.