Siete marcos de consultoría para la entrega de SAP e IA

Cuando un programa de SAP o de IA se atasca, la causa suele ser estructural, y siete marcos sencillos la encuentran. Documente el estado actual. Acuerde quién decide qué con un RACI. Vincule el trabajo a capacidades de negocio. Encuentre las causas raíz con los cinco porqués. Ordene los requisitos con MoSCoW. Ordene los riesgos según lo que realmente puede detener el programa. Haga un post-mortem de verdad al final de cada fase. Esta guía es para directores de programa, consultores y patrocinadores de la entrega de SAP e IA. Empiece por la tabla de abajo: busque su síntoma y use primero el marco correspondiente.

Una empresa de medios de tamaño medio de Qatar estaba desplegando SAP en varias regiones. Finanzas y compras salían a producción en la primera fase. También quería modelos de previsión con IA en sus informes.

En la semana seis, los retrasos empezaban a colarse. Los usuarios de negocio decían que habían aprobado los requisitos pero seguían sin tener claro qué iban a recibir. Se habían propuesto casos de uso de IA y nadie sabía decir quién era el responsable de los datos ni cómo se usaría el resultado. La gente llegaba tarde a las reuniones, o no llegaba.

Era esa fase intermedia. Demasiado pronto para llamarlo fracaso. Demasiado tarde para fingir que se arreglaría solo.

Aplicamos los marcos paso a paso. Al principio, no todo fue bien recibido. Algunas sesiones fueron silenciosas. Otras se desviaron. Pero la estructura facilitó el trabajo: el equipo dejó de dar vueltas, el backlog se volvió manejable y los casos de uso de IA consiguieron responsables reales. El proyecto entró en producción ocho semanas más tarde de lo previsto. No perfecto. Pero aterrizó, y la fase dos arrancó sobre mejor terreno, con menos incógnitas.

He usado versiones de los siete a lo largo de 23 años de entrega en programas de SAP, Oracle e IA en el Golfo, Europa y otras regiones. Ninguno es exótico. Todos funcionan si se aplican con disciplina y no como ejercicios de documentación.

Relacione el síntoma con el marco:

Síntoma que observa	Marco	Qué produce	Esfuerzo típico
Los usuarios aprobaron los requisitos pero siguen confundidos	1. Mapeo del estado actual	Un mapa compartido de cómo se trabaja de verdad hoy	De 3 a 5 días de talleres
Las decisiones rebotan de una reunión a otra	2. RACI en las decisiones críticas	Responsables con nombre para las 20 a 30 decisiones clave	Un taller, y luego seguimiento
Los patrocinadores se han desentendido de «el proyecto de TI»	3. Mapeo de capacidades	Avance reportado como capacidades de negocio	Integrado en el fit-to-standard
El mismo tipo de defecto sigue volviendo	4. Cinco porqués	Una causa raíz que se puede cambiar	Una sesión facilitada por problema
Todo está marcado como prioridad alta	5. MoSCoW	Un alcance ordenado con una lista realista de Must have	Una sesión conjunta de negocio y TI
El registro de riesgos parece correcto pero el equipo está tenso	6. Ranking de riesgos	Listas separadas de riesgos que detienen el programa y riesgos molestos	Revisión semanal de 30 minutos
Los mismos errores se repiten fase tras fase	7. Post-mortem	De tres a cinco cambios con responsables	Media jornada tras cada fase

El error más habitual al inicio de un programa es saltar a la solución antes de documentar lo que existe. La documentación de procesos suele estar desfasada. La gente describe cómo deberían funcionar las cosas, no cómo funcionan. La brecha entre ambas cosas es donde viven los problemas de implementación.

Un buen mapa del estado actual lleva de tres a cinco días de talleres con las personas que hacen el trabajo, no con quienes las dirigen. Recoge los pasos del proceso en orden, los sistemas utilizados en cada paso, las intervenciones manuales y las soluciones provisionales, y los flujos de datos entre departamentos.

Busque los pasos manuales que nadie menciona porque se han vuelto invisibles, las soluciones provisionales que llevan tanto tiempo funcionando que ya cuentan como proceso estándar, y los problemas de calidad de datos que todos conocen y nadie ha arreglado.

En Qatar, el mapa del estado actual salió de talleres con usuarios, no de la documentación. Ahí fue donde empezó a despejarse la confusión sobre los requisitos aprobados.

Bien hecho, un mapa del estado actual lleva días. Tratado como un ejercicio de recopilación de documentos, lleva meses y produce algo en lo que nadie confía.

Los derechos de decisión son el elemento estructural que más falta en los proyectos de SAP e IA. Todos tienen una opinión. Nadie sabe quién toma la decisión final. Las decisiones pasan a la reunión siguiente, que las remite al comité directivo, que las devuelve al grupo de trabajo.

Una matriz RACI (Responsible, Accountable, Consulted, Informed: quien ejecuta, quien responde, quien es consultado y quien es informado) da un responsable a cada decisión y a cada entregable. Una persona responde en última instancia (Accountable) y también puede ser quien ejecuta (Responsible) o delegarlo. Quienes son consultados (Consulted) aportan su opinión. Quienes son informados (Informed) conocen el resultado.

La versión práctica: haga una lista de las veinte o treinta decisiones más críticas de la fase actual y organice un taller RACI con quienes toman las decisiones presentes. Donde una asignación se discute, ha aprendido algo: o bien el gobierno no está claro, o bien hay una pelea política por la autoridad. En cualquier caso, hágalo aflorar en la semana dos, no en la catorce.

Un RACI sin cumplimiento es decoración. Los nombres deben corresponder a las personas con autoridad real. Asignar la responsabilidad final a un cargo en lugar de a una persona con nombre es una forma de evitar la conversación sobre quién asume el riesgo.

Los programas de SAP e IA generan mucha actividad técnica que el negocio no ve. El vínculo entre lo que se está construyendo y el resultado que debería entregar se vuelve abstracto. Los patrocinadores se desentienden y se culpa a «el proyecto de TI» de retrasos que en realidad son decisiones de negocio.

El mapeo de capacidades conecta la función del sistema con la capacidad de negocio: lo que la organización necesita ser capaz de hacer. En lugar de comprobar si el flujo de pedidos de compra está configurado, se comprueba si la organización puede procesar las facturas de proveedores en los tres días siguientes a su recepción. La configuración es el mecanismo. La capacidad es el resultado.

En SAP Activate esto se corresponde con los talleres de fit-to-standard de la fase Explore. Cada proceso incluido en el alcance es una capacidad, y cada brecha entre el estándar de SAP y la capacidad requerida es una decisión: aceptar el estándar, configurar una variante o extender. Mantener la conversación al nivel de las capacidades sostiene la atención del negocio durante el desarrollo, y deja al descubierto capacidades que todos daban por incluidas en el alcance pero que nadie confirmó.

Cuando el mismo tipo de problema aparece una y otra vez a lo largo de los sprints o las fases, parchear cada caso no sirve. La causa está más arriba.

Los cinco porqués son la herramienta de causa raíz más sencilla. Pregunte por qué ocurrió el problema, luego por qué ocurrió eso, hasta llegar a algo que pueda cambiar. Cinco rondas suelen llegar a la causa real. Dos rondas suelen quedarse en el síntoma.

Un ejemplo de migración de datos. La carga de prueba tiene errores de calidad de datos: ese es el síntoma. ¿Por qué? La extracción de origen tenía mapeos de campos equivocados. ¿Por qué? La especificación de mapeo nunca la revisó el responsable de datos del negocio. ¿Por qué? El responsable de datos se asignó solo cuando el mapeo ya estaba terminado. ¿Por qué? El plan no convertía la participación del responsable de datos en una dependencia del mapeo. Esa es la causa raíz, y la solución es una decisión de gobierno, no una corrección de datos. Mi artículo sobre por qué fracasa la migración de datos en SAP muestra con qué frecuencia aparece exactamente esta cadena.

1. 01Errores de la carga de pruebaEl síntoma
2. 02Mapeos de campos equivocados¿Por qué falló la carga?
3. 03Especificación sin revisar¿Por qué eran incorrectos los mapeos?
4. 04Responsable nombrado tarde¿Por qué no se revisó la especificación?
5. 05El plan omitió la dependencia¿Por qué se nombró tarde al responsable?

La causa raíz es una decisión de gobierno, no una corrección de datos

El análisis de causa raíz en una sala sin culpas produce respuestas honestas. En una sala donde se buscan culpables, produce actitud defensiva. El trabajo del facilitador es mantener la conversación en el proceso, no en las personas. Mi guía de pensamiento estructurado y resolución de problemas explica cómo descomponer un problema confuso antes de empezar a preguntar por qué.

Toda discusión de alcance en SAP e IA tiene una trampa de consenso. Nadie quiere hacer concesiones, así que todo pasa a ser prioridad alta. Cuando todo es prioridad alta, nada lo es, y el equipo de desarrollo intenta hacerlo todo.

MoSCoW (Must have, Should have, Could have, Won't have por ahora) obliga a elegir. Must have es el mínimo necesario para el go-live. Should have es importante pero no bloquea. Could have es deseable si el tiempo y el presupuesto lo permiten. Won't have se aplaza de forma explícita.

La disciplina está en la línea de los Must have. La primera pasada de un ejercicio MoSCoW suele poner demasiado en Must have. La guía DSDM del Agile Business Consortium, de donde viene MoSCoW, fija un techo del 60 % del esfuerzo en los Must have y advierte de que pasarlo pone en riesgo la entrega. La distancia entre la primera pasada y una lista realista son sobre todo supuestos sin comprobar.

Haga el MoSCoW con negocio y tecnología en la misma sala. Hechas por separado, la lista de Must have de TI y la del negocio resultan incompatibles, y nadie las concilia hasta que la configuración ya ha empezado.

La mayoría de los registros de riesgos son listas largas puntuadas por probabilidad e impacto, revisadas cada mes, con estados RAG que casi nunca se mueven. Registran el riesgo sin impulsar la acción.

Separe los riesgos que pueden detener el programa de los que solo lo dificultan. El primer grupo necesita responsables, planes de respuesta y visibilidad semanal. El segundo necesita seguimiento.

En Qatar, el registro de riesgos parecía correcto sobre el papel, pero todos estaban con los nervios de punta. Una matriz rápida de riesgo-impacto, revisada cada semana en lugar de cada mes, sacó a la luz las preocupaciones reales.

Un registro que parece estar bien mientras el equipo siente tensión casi siempre esconde algo. El registro no es la verdad; la verdad está en las conversaciones que lo rodean. Una revisión semanal que pregunta «¿qué le quitó el sueño anoche?» saca más a la luz que «¿cuál es el estado del punto 14?». Mi matriz de evaluación de riesgos de SAP ofrece una plantilla para la puntuación y la asignación de responsables.

Los post-mortem tras una fase o un go-live evitan que los mismos errores se repitan en la fase siguiente. También son lo primero que se recorta cuando el calendario aprieta.

Un post-mortem útil hace cuatro preguntas. ¿Qué planeamos lograr y qué logramos? ¿Qué salió bien y conviene repetir? ¿Qué salió mal y qué lo causó? ¿Qué haríamos de otra manera? Debe terminar con de tres a cinco acciones concretas con responsables, no con un documento que resuma lo ocurrido.

El fallo habitual es un ejercicio de justificación en el que los equipos defienden sus decisiones en lugar de examinarlas. Mantenga la mirada hacia adelante. La pregunta no es quién causó los retrasos de la semana seis. Es qué cambio estructural los evita en la fase siguiente.

En Qatar, el post-mortem se hizo justo después del go-live y se centró en la acción, no en la culpa. Es en buena parte la razón de que la fase dos arrancara sobre mejor terreno.

Los marcos no han cambiado. Lo que ha cambiado es cómo se aplican, de tres maneras.

Redactar se volvió más rápido; escuchar, no. Las herramientas de IA convierten ahora transcripciones de talleres y documentos de proceso en un primer mapa en cuestión de minutos, y SAP Cloud ALM puede redactar requisitos a partir de transcripciones de fit-to-standard. Los talleres en sí duran lo que siempre han durado, porque escuchar es el objetivo. El tiempo ahorrado en redactar debería dedicarse a contrastar el mapa con las personas.

Los borradores de RACI llegan listos, y lo difícil sigue ahí. Un asistente de IA de uso general produce un RACI a partir de un acta de constitución y una lista de paquetes de trabajo en un minuto. La disciplina pasa a ser la negociación: cada celda necesita una conversación real sobre autoridad y escalado. El tiempo ahorrado en construir el borrador debería dedicarse a esas conversaciones difíciles.

MoSCoW se vuelve más difícil con la IA en la sala. Un ranking de requisitos hecho por IA es plausible, pulido y a menudo equivocado respecto a la política local. Los consultores que lo aceptan sin cuestionarlo producen listas de prioridades peores que los que parten de una hoja en blanco. Trate el borrador de la IA como punto de partida, nunca como la respuesta.

El criterio con el que se aplican estos marcos vale más ahora, no menos. Si está desarrollando estas habilidades como consultor, las rutas profesionales de SAPopedia explican cuáles importan en cada etapa de una carrera en SAP.

¿Qué son los marcos de consultoría y por qué los usan los proyectos de SAP?

Son enfoques estructurados para el análisis, las decisiones y la resolución de problemas. En los programas de SAP e IA dan a los responsables de negocio, arquitectos, directores de proyecto, integradores y patrocinadores un método compartido.

Sin uno, cada grupo recurre a su propio modelo mental: resultados de proceso, arquitectura, o calendario y recursos. Marcos como el mapeo del estado actual, el RACI y MoSCoW hacen explícito el desacuerdo y lo vuelven resoluble. SAP Activate es en sí mismo un marco de fases, puntos de control y entregables; estos siete funcionan dentro de él y abordan los problemas estructurales y humanos que la metodología por sí sola no resuelve.

¿Cómo funciona el mapeo del estado actual en una implementación de SAP?

Documenta cómo funcionan realmente los procesos antes de que empiece la configuración, en contraposición a cómo dice la documentación existente que deberían funcionar. Constrúyalo en talleres con las personas que ejecutan los procesos: pasos, sistemas, traspasos, intervenciones manuales y soluciones provisionales.

Alimenta los talleres de fit-to-standard de la fase Explore de SAP Activate, donde el estado actual pasa a ser la línea base que se compara con los procesos estándar de SAP. Termínelo antes de que empiecen esos talleres, o su análisis de brechas se apoyará en suposiciones.

¿Qué es la priorización MoSCoW y cuándo se usa en los programas de SAP?

MoSCoW clasifica los requisitos en Must have, Should have, Could have y Won't have por ahora. Los Must have son el mínimo para el go-live; los Won't have se excluyen de forma explícita para que no puedan volver a colarse.

Resulta más útil en Explore, cuando los hallazgos de fit-gap impulsan las decisiones de extensión, y en Realize, cuando los defectos y las mejoras compiten por el tiempo de desarrollo. El problema habitual es que hay demasiados Must have en la primera pasada. DSDM recomienda no más del 60 % del esfuerzo en Must have; un facilitador que cuestione cada uno, con negocio y TI en la misma sesión, le lleva hasta ahí.

¿Cómo se hace una revisión de riesgos eficaz en un proyecto de SAP?

Como una conversación, no como una actualización de estado. Empiece con preguntas abiertas como «¿Cuál es su mayor preocupación esta semana que no esté en el registro?» antes de repasar el registro.

Para cada riesgo de prioridad alta, pregunte qué ha cambiado, qué acción se tomó, si la tendencia mejora y si el plan de respuesta sigue siendo adecuado. Los riesgos que permanecen en la misma calificación durante semanas sin acción suelen estar subestimados. Revise cada semana en las fases activas y muestre al comité directivo los cinco principales con su estado y la siguiente acción, no el registro completo.

¿Qué hace útil un post-mortem tras un go-live de SAP?

Cambios concretos y accionables para la fase siguiente. Un resumen de lo ocurrido es un registro, no un post-mortem.

Cubra lo que se proponía lograr, lo que logró, lo que funcionó y lo que no. Vaya más allá de las explicaciones superficiales como «teníamos pocos recursos»: ¿estaba mal el plan de recursos, el alcance o la vía de escalado? Termine con de tres a cinco cambios, cada uno con un responsable y una fecha.

¿Cómo ayudan los marcos de consultoría en la implementación de IA en entornos SAP?

Los proyectos de IA fracasan por las mismas razones estructurales que los de SAP, más algunas propias: datos sin responsable, medidas de éxito sin definir y ningún proceso acordado para actuar sobre el resultado.

El mapeo del estado actual muestra quién es el responsable de los datos que necesita un modelo y qué calidad tienen. El RACI responde quién valida el resultado, quién decide actuar sobre él y quién responde cuando es erróneo. MoSCoW separa los casos de uso esenciales de los simplemente interesantes. Empiece con dos o tres casos de uso esenciales con responsables y medidas de éxito claros, no con quince a la vez.