Evaluación de riesgos en proyectos SAP: la versión práctica

Una evaluación de riesgos de un proyecto SAP enumera lo que podría descarrilar el programa y puntúa cada riesgo según su probabilidad y su impacto. Cada riesgo tiene un único responsable con nombre y una respuesta acordada antes de que ocurra, y la lista se revisa cada semana. Los riesgos que hunden los programas SAP rara vez son sorpresas: migración de datos, integración, disponibilidad de las personas, deriva del alcance y adopción. Esta guía es para directores de programa y patrocinadores que quieren un registro de riesgos que cambie decisiones en lugar de quedarse en una carpeta. Incluye una matriz con puntuación, una plantilla de registro, tres fracasos públicos como casos prácticos y los riesgos que añaden RISE with SAP y clean core. Empiece por asignar un responsable con nombre a cada riesgo que ya tenga.

La mayoría de las evaluaciones de riesgos de SAP se construyen antes del primer comité directivo, se revisan una vez y no se vuelven a tocar. Eso no es gestión de riesgos. Es un documento.

He visto riesgos ignorados porque eran demasiado incómodos para plantearlos a tiempo. Ese silencio casi siempre sale más caro después. Lo que empieza como un pequeño problema de integración en Gestión de materiales de pronto bloquea a Finanzas. Un informe que parecía correcto en las pruebas se rompe tras una actualización del sistema. Lo he visto más de una vez.

Los riesgos no eran una sorpresa. Estaban documentados. Nadie actuó sobre ellos.

Alcance. El proyecto empieza con módulos estándar. Luego alguien añade «solo un informe más», después un panel, después unas cuantas ampliaciones. El peligro son los cambios de alcance que se introducen de manera informal en talleres, correos y conversaciones de pasillo, y de los que el director del proyecto se entera cuando la configuración ya está hecha. Mi guía para evitar la desviación del alcance explica los controles.

Recursos. Al arquitecto lo reasignan a una incidencia en producción. Se va un desarrollador clave. Los usuarios de negocio se pierden ciclos de pruebas porque su trabajo diario no se detiene. Consiga la disponibilidad por escrito. Las promesas verbales se evaporan bajo la presión sobre la plantilla.

Técnico. Mapeos de campos que nunca se validaron contra la estructura de destino. Interfaces que pasan las pruebas unitarias y se rompen con el volumen real de transacciones. Código personalizado que parece correcto hasta que llega la carga de producción. Todo esto es previsible si sabe dónde mirar.

Calendario. Un blueprint tardío comprime las pruebas, pero la fecha de go-live sigue fija. Las pruebas de aceptación de usuario (UAT), la formación y la preparación de datos se hacen con prisas. El mismo patrón aparece en casi todos los programas que incumplen un hito de fase y no mueven el plan posterior.

Adopción. La gente rechaza lo que no entiende. Una formación débil o tardía produce soluciones alternativas, las soluciones alternativas deterioran los datos y se culpa al sistema de lo que es un fracaso de la gestión del cambio.

Estos casos son públicos y están bien documentados. Los patrones se repiten a cualquier escala.

Lidl: unos 500 millones de euros en siete años

Lidl inició su proyecto eLWIS sobre SAP for Retail en 2011, salió en vivo en algunos países más pequeños y lo abandonó en 2018 con un costo reportado de unos 500 millones de euros. Una causa muy citada: Lidl valoraba el inventario a precio de compra, mientras que el modelo estándar de SAP para retail usa precios de venta. Lidl personalizó en lugar de cambiar su práctica, y la compañía dijo que los objetivos originales no podían alcanzarse con un esfuerzo razonable.

Lección: una diferencia entre su modelo de datos y el estándar de SAP es un riesgo de la primera semana, no un descubrimiento del quinto año.

HP: unos 400 millones de dólares en ingresos perdidos

En 2004 HP migró parte de su negocio de servidores a un sistema consolidado de pedidos y cadena de suministro basado en SAP. Los pedidos se caían entre el front end heredado y SAP y requerían trabajo manual, y la cartera de pedidos pendientes se duplicó. El CEO de HP dijo que los problemas costaron al grupo de servidores y almacenamiento unos 400 millones de dólares en ingresos y 275 millones de dólares en beneficio operativo, y dejaron una cartera de pedidos pendientes de 120 millones de dólares. El CIO de HP dijo después que el equipo había planificado tres semanas de interrupción y que debería haber tenido contingencia para entre cuatro y seis.

Lección: dimensione la contingencia para un cutover malo, no para uno promedio, y construya colchones de inventario o de canal antes de cambiar.

Nike: más de 100 millones de dólares en ventas perdidas

En 2000 Nike puso en marcha el software de planificación de la demanda de i2 antes de su programa de ERP SAP. El software estaba muy personalizado para funcionar con los sistemas heredados de Nike, iba lento y se caía con el volumen de productos. Pedía demasiado de unos modelos de zapatillas y muy poco de otros. Nike perdió más de 100 millones de dólares en ventas y sus acciones cayeron cerca de un 20 %. Más tarde Nike trasladó la planificación a corto y medio plazo a SAP.

Lección: no dé por hecho que una integración funciona hasta que haya corrido con volumen de producción y datos reales.

Una evaluación construida sobre suposiciones es peor que ninguna, porque crea una falsa confianza. Seis datos de partida importan:

1. Documentación del alcance: acta de constitución, alcance aprobado y requisitos firmados. Si no existen, el riesgo de alcance ya es alto.
2. Compromisos de recursos: compromisos por escrito de los jefes de departamento, una matriz de competencias para los roles críticos y un suplente con nombre para cada puesto clave.
3. Presupuesto y calendario: presupuesto aprobado con contingencia y un calendario contrastado con programas comparables. Seis meses y financiación mínima para un despliegue completo es un riesgo que debe señalar ahora.
4. Compromisos del proveedor: contratos con niveles de servicio y penalizaciones. En RISE, las responsabilidades de SAP y su vía de escalación.
5. Entorno técnico: compatibilidad con sistemas heredados, complejidad de la migración de datos, modelo de despliegue y un plan de clean core para cualquier desarrollo a medida.
6. Registros de proyectos anteriores: registros de riesgos, registros de incidencias y análisis posteriores de programas SAP o ERP previos. La mayoría de los riesgos no son nuevos.

Puntúe cada riesgo en probabilidad e impacto de 1 a 5 y multiplique. El ejemplo siguiente es un punto de partida típico para un programa S/4HANA; sus puntuaciones serán distintas.

Riesgo	Probabilidad (1-5)	Impacto (1-5)	Puntuación	Prioridad
Fallo en la migración de datos	4	5	20	Alta
Retrasos de integración	4	4	16	Alta
Limitaciones de recursos	4	4	16	Alta
Desviación presupuestaria	3	5	15	Media
Código personalizado en el core que bloquea las actualizaciones	3	5	15	Media
Desviación del alcance	4	3	12	Media
Lagunas en la cobertura de pruebas	3	4	12	Media
Rendimiento con carga máxima	3	4	12	Media
Brechas de cumplimiento normativo	2	5	10	Media
Sin vía de escalación hacia SAP (RISE)	2	5	10	Media
Baja adopción por parte de los usuarios	3	3	9	Media
Exposición a costos de suscripción o licencias	2	4	8	Media
KPI sin seguimiento	3	2	6	Baja

Las puntuaciones de 16 o más requieren un responsable con nombre y acción inmediata. Las de 8 a 15 requieren seguimiento con un umbral de escalación definido. Por debajo de 8, mantenga el riesgo en el registro sin dedicarle tiempo prioritario. Las puntuaciones son un punto de partida, no un veredicto: una brecha de cumplimiento puntuada con 10 puede pasar a 25 en un sector regulado.

Una puntuación por sí sola no cambia nada. Cada riesgo necesita estos campos, rellenados.

Campo	Qué escribir	Ejemplo
Riesgo	El evento, en una frase	Los datos maestros de proveedores no se depuran antes de la carga simulada 2
Responsable	Una persona con nombre	Responsable de cuentas por pagar
Puntuación	Probabilidad × impacto	4 × 5 = 20
Umbral de activación	El punto medible en el que se actúa	Tasa de duplicados superior al 5 % en la extracción de la carga simulada 1
Respuesta	Evitar, mitigar, transferir o aceptar, con la acción	Mitigar: dos analistas de cuentas por pagar dedicados a la depuración durante tres semanas
Próxima revisión	Fecha	La revisión de riesgos del próximo lunes
Estado	Abierto, en acción, cerrado	En acción

Exprese el costo en términos reales siempre que pueda. «Riesgo alto» es vago. «Un retraso de una semana en la UAT cuesta del orden de seis cifras en tiempo del equipo y puede retrasar el go-live tres semanas» llama la atención.

El código personalizado es una categoría de riesgo en sí misma. En S/4HANA Cloud Public Edition no es posible el código personalizado en el core. Las extensiones pasan por SAP BTP, las API publicadas o las herramientas para key users. En nube privada y on-premise todavía puede modificar el core, y los socios acostumbrados a hacerlo lo harán. Esa deuda técnica aflora en la primera gran actualización. Haga seguimiento de cuántas personalizaciones identificadas tienen un enfoque de clean core acordado, compruebe la experiencia del socio con extensiones en BTP y ponga en marcha un foro de revisión antes de que termine Explore.

RISE cambia quién es responsable de la disponibilidad. SAP gestiona la infraestructura, de modo que el riesgo pasa de «nuestro equipo es responsable de la disponibilidad» a «SAP es responsable de ella y necesitamos una forma rápida de llegar a SAP cuando algo falla». Registre los contactos con nombre de SAP, la vía de escalación y los niveles de servicio, y un plan de incidentes acordado antes del go-live. Sin ellos, los problemas que deberían ir a SAP permanecen demasiado tiempo dentro del equipo del proyecto.

La IA ayuda con el papeleo, no con el criterio. Los asistentes basados en Joule de SAP Cloud ALM y herramientas como Microsoft Copilot pueden redactar entradas del registro y paquetes para el comité directivo a partir de informes de estado, registros de defectos y actas. Eso acelera el mantenimiento del registro en programas con datos de origen limpios. Encuentra riesgos que ya son visibles en los datos. No decide qué riesgos merecen acción, no consigue que los responsables actúen ni escala los riesgos que la dirección preferiría ignorar.

1. Identifique los riesgos en las cinco categorías. Organice talleres con TI, el negocio y los proveedores; cada uno ve riesgos distintos. En RISE, incluya a los contactos de SAP en al menos uno. Los riesgos que los equipos suelen pasar por alto: TI y el negocio que esperan cosas distintas, integraciones externas mal definidas, responsables de UAT que no están disponibles y cambios de alcance informales.
2. Puntúe cada riesgo en probabilidad e impacto, con números reales siempre que sea posible.
3. Asigne un responsable por riesgo. Una persona, no un equipo. Sin responsable no hay seguimiento ni resolución.
4. Defina la respuesta antes de que el riesgo llegue. Evitar, mitigar, transferir o aceptar. «Vigilar y responder» no es un plan. Es una decisión aplazada.
5. Revise cada semana. Compruebe los riesgos abiertos, añada los nuevos, vuelva a puntuar donde hayan cambiado las condiciones y escale todo lo que esté cerca de su umbral. Lleve los riesgos principales al comité directivo con una propuesta de decisión en lugar de un color.

1. 01IdentificarLas cinco categorías
2. 02PuntuarProbabilidad × impacto, de 1 a 5
3. 03Asignar un responsableUna persona, no un equipo
4. 04Definir la respuestaEvitar, mitigar, transferir o aceptar
5. 05Revisar cada semanaVolver a puntuar, escalar cerca de los umbrales

16 o más: un responsable con nombre y acción esta semana

¿Qué es una evaluación de riesgos en un proyecto SAP?

Es el proceso de identificar qué podría salir mal, puntuar cada riesgo por probabilidad e impacto, asignar un responsable a cada uno y acordar una respuesta antes de que ocurra. Los programas SAP gestionan a la vez varios módulos, integraciones, una migración de datos, un programa de cambio y un go-live fijo, de modo que la gestión informal de riesgos no se sostiene. Una lista corta de riesgos reales con responsables vale más que un documento largo que nadie lee.

¿Cómo se construye una matriz de riesgos para un proyecto SAP?

Enumere los riesgos de alcance, recursos, técnicos, calendario y adopción, además de clean core y la escalación hacia SAP en RISE. Puntúe cada uno en probabilidad e impacto de 1 a 5 y multiplique. Considere 16 o más como alto, de 8 a 15 como medio y menos de 8 como bajo. Dé a cada riesgo medio y alto un responsable y un umbral medible, como «si la finalización de la UAT está por debajo del 80 % en la semana 16, la fecha de go-live pasa a revisión». Vuelva a puntuar cada semana y en cada hito de fase.

¿Cuáles son los riesgos más habituales en las implementaciones de SAP?

Fallo en la migración de datos, porque los datos heredados casi siempre están más desordenados de lo estimado. Retrasos de integración, sobre todo con interfaces heredadas sin documentar y proveedores externos. Desviación del alcance que comprime las pruebas y la formación. Limitaciones de recursos, como personas clave que se retiran o usuarios no disponibles durante la UAT a fin de mes. Baja adopción por una formación que muestra pantallas en lugar de simular el trabajo. En RISE, añada el código personalizado en el core y la falta de una vía de escalación hacia SAP.

¿Cuándo debe hacerse una evaluación de riesgos durante un proyecto SAP?

Antes de que empiece el proyecto, cuando los riesgos estructurales, como las diferencias en el modelo de datos o los calendarios poco realistas, son más baratos de corregir. Antes de cada hito de fase de SAP Activate, porque cada fase cambia el perfil de riesgo. Cada vez que cambien el alcance, el presupuesto o los recursos. Y cuando un riesgo se convierte en problema, para comprobar qué más afecta. Entre medias, revise cada semana.

¿Quién debe ser responsable de los riesgos en un programa SAP?

La persona que puede actuar sobre ellos. El responsable de datos se encarga del riesgo de migración de datos, el arquitecto técnico del riesgo de integración, el responsable del cambio del riesgo de adopción y el arquitecto de soluciones del riesgo de clean core. En RISE, el CIO o el director del programa es responsable de la vía de escalación hacia SAP. El director del programa vigila la salud del registro, pero no es responsable de todos los riesgos.

¿Qué ocurre cuando se omite la evaluación de riesgos de un ERP?

A gran escala, se dan casos como el de Lidl, que abandonó su proyecto SAP de retail en 2018 tras unos 500 millones de euros. O el de HP, cuya migración del sistema de pedidos SAP en 2004 costó a su grupo de servidores unos 400 millones de dólares en ingresos. A menor escala el mecanismo es el mismo: diferencias en el modelo de datos descubiertas tarde, integraciones que fallan con volumen de producción y fracasos de adopción por una formación débil. Los riesgos eran identificables antes de convertirse en problemas.