Elegir qué ERP conservar puede parecer la primera decisión de una fusión. Pero esa elección no resuelve quién aprobará una compra, con qué criterios se gestionará la información o qué diferencias entre las organizaciones seguirán teniendo sentido. Unificar el sistema no equivale a acordar cómo debe funcionar la empresa resultante.
Cuando esas cuestiones permanecen abiertas, el calendario puede dar una impresión de avance mientras el alcance sigue en discusión. La asistencia para la implantación de un ERP debe empezar, por tanto, antes de la configuración: aclarando qué necesita el negocio, quién puede decidir y bajo qué condiciones se pasará a la ejecución.
Ese es el ámbito de la práctica AMOA de OLING: estructurar la necesidad, definir el marco del proyecto y alinear a las partes interesadas antes de ejecutar. La intervención puede situarse al inicio o al revisar un planteamiento que ha perdido claridad. El enfoque consiste en delimitar el problema, aclarar las expectativas y formalizar los entregables para avanzar por etapas.
1. Acordar el funcionamiento común antes de elegir la herramienta
«Trabajar con un único ERP» describe una opción de arquitectura, no un objetivo de negocio suficiente. No explica si todas las unidades compartirán circuitos de aprobación, criterios de gestión o responsabilidades. Tampoco permite distinguir una diferencia necesaria de una costumbre heredada.
Antes de traducir la convergencia en requisitos técnicos, conviene clasificar los procesos en tres grupos:
- Comunes: reglas, información y procesos que la organización resultante necesita compartir.
- Específicos: particularidades justificadas por la actividad, las obligaciones aplicables o las necesidades operativas.
- Transitorios: diferencias que no forman parte del modelo objetivo, pero cuya eliminación exige condiciones previas.
Un mapa de procesos organizado de este modo puede servir de soporte para las decisiones. Su utilidad no está en representar todo el sistema futuro, sino en mostrar qué está acordado, qué sigue pendiente y qué depende de otra decisión.
La distinción es importante: integrar no exige necesariamente uniformar. Pero conservar una excepción tampoco debería justificarse solo porque una de las organizaciones siempre haya trabajado así.
2. Separar la necesidad de negocio de la solución heredada
«Mantener este módulo» o «replicar este circuito» son peticiones comprensibles, aunque ambas anticipan una solución. Aceptarlas directamente como requisitos puede trasladar al nuevo ERP decisiones que todavía no se han contrastado.
OLING identifica dos dificultades recurrentes en AMOA: necesidades mal formuladas entre negocio y sistemas, y decisiones difíciles de resolver por falta de prioridades explícitas. En una fusión, conviene abordar ambas a la vez: precisar qué se necesita y establecer qué pesa más cuando las peticiones entran en conflicto.
Para trabajar una petición, las preguntas útiles son concretas:
- ¿Qué actividad o decisión de negocio debe permitir realizar?
- ¿Qué usuarios y responsables intervienen, y dónde difieren las prácticas actuales?
- ¿Qué condición es obligatoria y qué elemento responde a una preferencia?
- ¿Con qué criterio se aceptará la respuesta propuesta?
Por ejemplo, ante la petición de reproducir un informe, conviene preguntar qué decisión permite tomar, qué información necesita y quién responde de ella. Así se puede definir el servicio esperado sin convertir el formato existente en una obligación. No se trata de descartar lo que funciona, sino de saber por qué debe mantenerse.
3. Dar autoridad y criterios a las decisiones pendientes
Recoger necesidades no resuelve los desacuerdos. Dos áreas pueden apoyar la integración y discrepar sobre las reglas comunes, las excepciones admisibles o el cambio que debe posponerse. Un taller adicional no sustituye a una decisión que corresponde a la dirección.
La gobernanza debería distinguir quién prepara las opciones, quién aporta las restricciones y quién tiene autoridad para resolver. La persona responsable del proyecto no debería asumir por defecto decisiones de negocio para las que no tiene mandato.
Un registro de decisiones puede reunir el asunto pendiente, las alternativas, el responsable de resolverlo, los criterios de elección y las consecuencias de mantenerlo abierto. Su valor no está en documentar cada conversación: está en impedir que una cuestión sin resolver se trate como una hipótesis validada.
La práctica AMOA de OLING incluye identificar a las partes interesadas y las decisiones que deben tomarse. También señala el patrocinio explícito y las prioridades compartidas como factores de éxito. En este contexto, el apoyo directivo debería traducirse en capacidad efectiva para resolver conflictos, no limitarse a aprobar el lanzamiento del proyecto.
4. Convertir el encuadre en documentos que orienten la ejecución
OLING contempla tres entregables habituales de AMOA: una nota de encuadre, un backlog o una hoja de ruta y una síntesis de gobernanza. Aplicados a una renovación de ERP durante una fusión, conviene que respondan a preguntas distintas y mantengan una base coherente.
Nota de encuadre: ¿qué proyecto se está autorizando?
Debería expresar el problema, los objetivos, el alcance y las exclusiones. También conviene separar las decisiones validadas de las hipótesis abiertas. Esa distinción permite entender qué se está aprobando y qué sigue sujeto a confirmación, sin presentar toda la definición como definitiva.
Backlog u hoja de ruta: ¿en qué orden se puede avanzar?
Debería ordenar las necesidades y los pasos según prioridades y dependencias. Una lista de tareas no basta si no explica por qué una actuación precede a otra o qué condición permite iniciarla. La secuencia debe responder a las condiciones del proyecto, no solo al deseo de avanzar en todos los frentes a la vez.
Síntesis de gobernanza: ¿dónde se resuelve un bloqueo?
Debería aclarar responsabilidades, instancias de decisión y vías de escalado. Quien detecte una cuestión que afecta al alcance debe poder saber quién la prepara y dónde se resuelve.
Estas son orientaciones para aplicar los entregables al contexto ERP, no una especificación cerrada. Una prueba sencilla permite valorar su utilidad: si cambia una prioridad, ¿se puede identificar qué parte del alcance, de la secuencia o de las responsabilidades debe revisarse?
5. Definir la transición, no solo el destino
Acordar el funcionamiento objetivo no determina automáticamente cómo llegar a él. La hoja de ruta debería distinguir ese destino de las condiciones necesarias para alcanzarlo: responsabilidad sobre los datos, dependencias con otros sistemas, disponibilidad de las áreas operativas y criterios de aceptación.
No es necesario diseñar toda la solución durante el encuadre. Sí conviene identificar qué incertidumbres pueden cambiar el alcance o la secuencia antes de comprometer la implantación.
Si se prevé una coexistencia temporal de sistemas o procesos, debería explicitarse para qué sirve y qué permitirá abandonarla. Una transición necesita una condición de salida, no solo una fecha prevista. Sin ella, lo provisional puede convertirse en complejidad permanente. En sentido contrario, imponer la convergencia sin comprobar sus requisitos previos puede trasladar las dificultades a la operación.
Cuándo revisar el planteamiento sin detener todo el proyecto
OLING señala dos puntos de vigilancia en AMOA: confundir la necesidad de negocio con la elección de herramienta y acumular decisiones sin resolver. En un proyecto ERP, conviene prestar atención cuando los talleres reabren los mismos debates, las excepciones crecen sin criterio compartido o nadie puede explicar las hipótesis que sostienen el calendario.
Estas señales justifican revisar la base de trabajo, no paralizar automáticamente el proyecto. La respuesta puede ser acotada: reformular una necesidad, elevar una decisión al nivel adecuado o corregir una dependencia. El propósito no es prolongar el análisis, sino dejar de planificar sobre cuestiones que siguen abiertas.
El criterio para pasar a la ejecución
Antes de ejecutar, dirección, sistemas y áreas de negocio deberían poder explicar el mismo alcance, reconocer las decisiones pendientes y compartir los criterios para resolverlas. No hace falta eliminar toda incertidumbre; hace falta distinguir lo acordado de lo pendiente y asignar la responsabilidad de resolverlo.
El encuadre no garantiza una implantación sin desviaciones. Su valor está en hacer explícitos los objetivos, las responsabilidades y los compromisos sobre los que se construirá el proyecto. Si esas bases no coinciden entre los equipos, añadir detalle al calendario no resolverá la diferencia.
Hablar con OLING sobre el encuadre de su proyecto ERP: aclarar qué necesita decidir la organización antes de comprometer la implantación.