Planificación y control de proyectos SAP: cómo mantenerlos en rumbo

La mayoría de los programas SAP tienen un plan. Muchos menos tienen control. La planificación fija el alcance, el calendario, el presupuesto y los riesgos. El control es el trabajo semanal de seguir el avance frente a ese plan, gestionar las dependencias, escalar a tiempo y evaluar cada cambio antes de aprobarlo. Esta guía es para directores de programa, PMO y patrocinadores cuyo programa SAP se está desviando, o que quieren evitar que se desvíe. Explica cómo es el control, tres fracasos públicos que muestran qué ocurre sin él y una cadencia semanal de control con responsables que puede adoptar esta misma semana.

Al principio de mi carrera trabajé en un programa SAP que sobre el papel era impecable. Calendarios, registros de riesgos, registros de cambios, todo lo que cabría esperar. Nadie lo seguía. El comité directivo rara vez se reunía. Finanzas esperaba la migración de datos. TI no había empezado. Nadie hacía seguimiento de las dependencias. Todos daban por hecho que otro mantenía las cosas en rumbo.

En el sexto mes, la mitad del proyecto iba con retraso y andábamos persiguiendo nuestros propios errores. Lo peor era que nadie lo vio venir.

No era un problema de planificación. Era un problema de control. No había una asignación real de recursos, ni una mitigación de riesgos adecuada, ni una vía de escalado. El plan se había elaborado una vez y después se abandonó en favor de las reuniones.

La planificación abarca el alcance, el calendario, el presupuesto, los recursos, el registro de riesgos y los compromisos de hitos. La mayoría de los equipos lo elabora. La cuestión es si alguien lo usa de una semana a otra.

El control abarca el seguimiento del avance real frente al plan, sacar a la luz las desviaciones pronto, gestionar las dependencias, escalar cuando algo se retrasa y restablecer la línea base cuando el alcance o el calendario cambian formalmente. La mayoría de los equipos lo hace mal.

1. 01Seguir el avanceReal frente al plan, por paquete de trabajo
2. 02Sacar a la luz las desviacionesCualquier tarea con tres días de retraso
3. 03Revisar las dependenciasQuién queda bloqueado si esto se retrasa
4. 04EscalarPor una vía acordada de antemano
5. 05Evaluar los cambiosPrimero el tiempo, el costo y los recursos
6. 06Restablecer la línea baseSolo después de un cambio formal

Cada semana, con responsables designados

Esto es lo que se rompe cuando falta control:

Lo que se rompe sin control	Por qué ocurre
Los plazos se retrasan en silencio	Nadie revisa entre una revisión de hito y la siguiente
Los supuestos no se verifican	Cada equipo espera que otro se ocupe de la dependencia
El alcance crece de manera informal	Cambios aprobados en reuniones sin evaluación de impacto
Los riesgos se ignoran hasta que se materializan	El registro de riesgos se actualiza cada trimestre en lugar de cada semana
Los costos superan el presupuesto	El esfuerzo está en las hojas de horas pero no se asigna a paquetes de trabajo
Los equipos dejan de comunicarse	Las reuniones de seguimiento se convierten en puestas al día sin acciones

Son casos públicos, no historias de clientes. Sus causas de fondo son las que veo una y otra vez en mi trabajo de asesoría.

Lidl: unos siete años y unos 500 millones de euros estimados, y después se detuvo

Lidl inició su proyecto eLWIS en SAP Retail en 2011. Su práctica de valoración de inventarios difería del modelo estándar de SAP, y Lidl decidió adaptar el software en lugar de la práctica. En 2018 el sistema estaba en producción en Austria, Irlanda del Norte y Estados Unidos, pero el consejo de administración concluyó que los objetivos originales no se podían alcanzar a un costo razonable. Lidl detuvo el proyecto y volvió a desarrollar su sistema propio. La prensa especializada estimó el gasto en unos 500 millones de euros, y el miembro del consejo responsable de TI se había marchado en 2017. Heise informó de la decisión en julio de 2018. La lección: años de personalización para proteger una práctica heredada son un fallo de control, no un fallo del software.

Hershey: unos 100 millones de dólares en pedidos de Halloween sin entregar

El nuevo sistema de SAP, Siebel y Manugistics de Hershey estaba previsto para entrar en producción en abril de 1999, un mes tranquilo para la confitería. Se retrasó tres meses y salió en julio, justo cuando empezaban a llegar los pedidos de Halloween. Los pedidos no lograban pasar del sistema a los almacenes. El director general dijo a los analistas que los problemas impedirían a Hershey entregar unos 100 millones de dólares en producto para Halloween, y las ventas del tercer trimestre cayeron un 12,4 %. El relato de la revista CIO atribuye el verdadero fracaso al momento elegido. Un control del calendario que protegiera la temporada alta habría obligado a fijar otra fecha de go-live.

Revlon: una planta afectada y una debilidad material en los controles

Revlon puso en marcha SAP en su planta de Oxford, Carolina del Norte, su mayor centro de fabricación, en febrero de 2018. Las interrupciones del servicio afectaron a la fabricación y a los envíos a grandes minoristas de Estados Unidos. En marzo de 2019 Revlon reveló una debilidad material en el control interno vinculada al despliegue, citando la ausencia de una evaluación continua eficaz de riesgos y la escasez de personal formado en las operaciones afectadas. Los inversores demandaron; TechTarget cubrió la demanda, que alegaba que unos 64 millones de dólares en envíos quedaron sin cumplir.

Ninguno fracasó porque SAP fuera una mala elección. Fracasaron en fundamentos de planificación y control que existen desde hace décadas.

Estructura de desglose del trabajo

Una estructura de desglose del trabajo (EDT) divide el alcance total en entregables con responsables claros. Sin ella, el trabajo es invisible hasta que llega tarde. En un programa SAP abarca el diseño de procesos, la configuración, la migración de datos, la integración, las pruebas, la formación y el cutover, cada uno desglosado en tareas con un responsable y una fecha de vencimiento.

El valor no está en el documento. Obliga a conversar sobre qué hay que hacer, quién lo hace y de qué depende. Las dependencias son lo que mata los proyectos. Un retraso en la migración de datos bloquea las pruebas de integración, que bloquean las pruebas de aceptación de usuario (UAT), que estrechan la ventana del cutover. Una EDT hace visible esa cadena.

Gestión del calendario

Los calendarios fallan por razones previsibles. A la gente se la llevan a otras tareas. Las estimaciones eran erróneas. Las decisiones tardan más de lo previsto. Incorpore holgura desde el primer día, como un margen explícito junto a las tareas con más probabilidad de necesitarlo, no como un relleno repartido por todas partes.

Haga seguimiento del calendario cada semana. Un retraso de una semana en la semana cuatro es una conversación. Un retraso de cuatro semanas en la semana dieciséis es una crisis. El mismo problema, un costo de corrección muy distinto.

Trate el momento del go-live como una decisión propia. Nunca salga en vivo en plena temporada alta del negocio. La lección de Hershey vale para cualquier empresa.

Control del presupuesto

Los presupuestos se rompen por tres motivos: cambios de alcance sin gestionar, una migración de datos subestimada y costos de hypercare superiores a las estimaciones iniciales. Haga seguimiento del gasto real frente al plan desde la primera semana. Cuando una desviación llega al comité directivo, normalmente ya es tarde para corregirla sin trastornos.

El control de cambios es la principal protección del presupuesto. Todo cambio de alcance recibe una evaluación de impacto en tiempo, costo y recursos antes de aprobarse. Si la evaluación llega después de la aprobación, el cambio se ha saltado el presupuesto. Mi guía sobre cómo evitar el crecimiento descontrolado del alcance en las implementaciones de SAP profundiza en el comité de cambios.

Gestión de riesgos

Un registro de riesgos que se mantiene cada trimestre es puro teatro. Los riesgos necesitan una revisión semanal, responsables designados y planes de respuesta. Nómbrelos en todo programa SAP: calidad de datos descubierta tarde, retrasos de integración, carencias en la disponibilidad de recursos, compresión de la ventana de cutover y mala adopción por parte de los usuarios.

Un cliente perdió tres meses cuando su proveedor de migración de datos incumplió plazo tras plazo. Seguíamos oyendo «solo dos semanas más» hasta que fue demasiado tarde para cambiar de proveedor sin reventar el presupuesto. Un riesgo con un responsable y una fecha de activación habría forzado esa decisión meses antes. Mi matriz de evaluación de riesgos de SAP ofrece una plantilla para puntuar y asignar estos riesgos.

Comunicación y escalado

Los directivos necesitan titulares. Los equipos de entrega necesitan detalles concretos. Los jefes de proyecto necesitan datos de desviación. Una misma actualización para todos no ayuda a nadie.

Documente y ensaye las vías de escalado antes de una crisis. En una implementación de SAP, TI daba por hecho que finanzas estaba revisando la configuración y finanzas daba por hecho que lo hacía TI. Nadie lo planteó hasta que el go-live estaba a tres meses y no había aprobaciones críticas; la solución fue una carrera de última hora, un costo adicional y un despliegue retrasado. Otra empresa lo hizo bien: los informes estaban estructurados y ligados a acciones, así que cuando surgía un problema, todos sabían quién era el responsable, cuál era el impacto y cómo se resolvería.

El alcance es donde el escalado demuestra su valor. Trabajé con una aerolínea que empezó con una simple mejora del sistema de reservas. A los seis meses había añadido cambios de fidelización, programación de tripulaciones y módulos de finanzas. Ninguno era urgente. Nadie dijo que no. El calendario se duplicó y los costos subieron un 70 %.

El manual de la era on-premise no sobrevive intacto a RISE with SAP. Hay tres cosas distintas.

RISE cambia ante quién se escala

Con RISE with SAP, SAP gestiona la infraestructura y las operaciones técnicas y aporta un equipo de éxito del cliente que sigue la adopción. Su estructura de control tiene que incluirlos. Para los problemas de plataforma (rendimiento del sistema, región del hiperescalador, niveles de servicio de SAP), el director del programa necesita una vía de escalado documentada hacia SAP que no pase por el socio de implementación. Déjela por escrito antes de necesitarla.

Clean Core da al control del alcance un respaldo técnico

Cada brecha exige ahora una decisión: configurarla, extenderla mediante API publicadas (on-stack con ABAP Cloud o side-by-side en SAP BTP) o rechazarla. En S/4HANA Cloud Public Edition, modificar el núcleo no es una opción. En la edición privada y en on-premise es posible, pero la guía de Clean Core de SAP lo trata como último recurso, porque cada modificación añade trabajo de actualización.

Eso ayuda a controlar el alcance. Una petición de «retocar un poco el proceso estándar de order-to-cash» deja de ser una charla informal de configuración y pasa a ser una extensión con esfuerzo de diseño, construcción y pruebas. Cree un pequeño foro de revisión de extensiones por debajo del comité directivo, con un arquitecto que tenga autoridad para aprobar o rechazar. Sin él, todas las discusiones sobre personalización acaban en el comité directivo.

La IA redacta los informes, las personas toman las decisiones

Hoy la IA ayuda con el papeleo del control. SAP Cloud ALM, la herramienta de gestión del ciclo de vida de aplicaciones de SAP, contiene las tareas del proyecto, los requisitos y el estado de las pruebas, y puede generar borradores de requisitos a partir de las transcripciones de los talleres. Microsoft Copilot redacta resúmenes de desviaciones para los paquetes del comité directivo a partir de paneles e informes de estado. La detección de anomalías en Power BI o SAP Analytics Cloud señala los KPI que se apartan de su patrón habitual. Es útil para el uso de recursos, el volumen de solicitudes de cambio y los tickets de soporte, menos para métricas que oscilan de forma natural.

Lo que la IA no hace es actuar. Un panel puede mostrar en rojo el retraso del calendario durante seis semanas. Si el comité directivo no hace nada, el retraso continúa.

Este es el ritmo mínimo para un programa en plena ejecución. Si falta alguna fila, añádala antes que nada.

Control	Práctica mínima	Responsable	Frecuencia
Estructura de desglose del trabajo	Cada tarea tiene un responsable, una fecha de vencimiento y sus dependencias	Responsable de la PMO	Actualizada cada semana
Revisión del calendario	Marcar cualquier tarea con más de tres días de retraso; revisar la ruta crítica	Director del programa	Semanal
Seguimiento del presupuesto	Real frente al plan por paquete de trabajo	Responsable de finanzas del programa	Semanal, con informe mensual
Revisión de riesgos	Cada riesgo activo tiene un responsable, un detonante y una respuesta	Responsables de cada línea de trabajo	Semanal
Control de cambios	Evaluación de impacto en tiempo, costo y recursos antes de la aprobación	Presidente del comité de cambios	Semanal o a medida que llegan las solicitudes
Revisión de extensiones (RISE y GROW)	Decisión de configurar, extender o rechazar para cada brecha	Arquitecto de soluciones	Quincenal
Comité directivo	Decisiones, no informes de estado; documentos enviados con antelación	Patrocinador ejecutivo	Quincenal; semanal en cutover y hypercare

La mayoría de los fallos de planificación y control no se deben a que el método fuera erróneo, sino a que la disciplina se abandonó hacia el cuarto mes. Mantenga la cadencia lo bastante ligera como para que el equipo la siga aplicando en el mes catorce. Para el propio comité directivo, vea mi guía sobre cómo crear un comité directivo eficaz en un proyecto SAP.

¿Cuál es la diferencia entre la planificación y el control de un proyecto?

La planificación produce la hoja de ruta: alcance, calendario, presupuesto, recursos y riesgos. Fija el rumbo al principio.

El control es el trabajo continuo de seguir el avance frente a ese plan, sacar a la luz las desviaciones, gestionar las dependencias y restablecer la línea base cuando se producen cambios formales. Ocurre cada semana durante toda la vida del programa.

La mayoría de los programas SAP invierten mucho en planificación y demasiado poco en control. Cuando la desviación aparece en el comité directivo, ya se han acumulado semanas o meses de costo de recuperación.

¿Por qué fracasan los proyectos SAP aunque tengan un plan?

Porque nadie trabaja el plan. No se hace seguimiento de las dependencias, así que el retraso de una línea de trabajo bloquea en silencio a otra. Los registros de riesgos se actualizan cada trimestre. Los cambios de alcance se aprueban de manera informal. El comité directivo se reúne una vez al mes y ve resúmenes de hitos que ocultan lo que ocurre sobre el terreno.

Lidl, Hershey y Revlon tenían planes. Lo que les faltó fue un control activo: un seguimiento honesto, un escalado temprano y una respuesta real cuando aparecieron las señales de alerta.

¿Cómo gestiono el crecimiento descontrolado del alcance en un programa SAP largo?

Dé a cada cambio de alcance una evaluación de impacto por escrito antes de aprobarlo: tiempo, costo y recursos. Sin ella, aprobar un cambio es aprobar una incógnita.

La regla más eficaz: toda adición debe desplazar otra cosa. Esa sola restricción obliga a los responsables de negocio a priorizar con honestidad.

Los directivos tienen que respaldarla. Cuando un CFO o un COO apoya públicamente el control de cambios, las peticiones informales caen rápido. En los programas con RISE y GROW, la decisión sobre extensiones para cada brecha añade una comprobación técnica adicional.

¿Qué es una estructura de desglose del trabajo y por qué importa en SAP?

Una EDT divide el alcance total en entregables, cada uno con un responsable y una fecha de vencimiento. En un programa SAP eso significa diseño de procesos, configuración, migración de datos, integración, pruebas, formación y cutover, todo desglosado en tareas.

Su valor práctico es el mapa de dependencias. La migración de datos alimenta las pruebas de integración, que alimentan las UAT, que alimentan el cutover. Cuando una se retrasa, el impacto en las siguientes se ve de inmediato.

¿Cómo cambia RISE with SAP la planificación y el control de un proyecto?

SAP pasa a participar en la entrega. Gestiona la infraestructura y las operaciones técnicas, y su equipo de éxito del cliente sigue su propia cadencia sobre adopción y valor.

De ahí se derivan tres cambios. Hace falta una vía de escalado documentada hacia SAP para los problemas de plataforma que no pase por el socio. Hace falta un foro de revisión de extensiones por debajo del comité directivo para decidir cómo se trata cada brecha bajo Clean Core. Y conviene integrar la cadencia de éxito del cliente de SAP en su gobernanza en lugar de ejecutarla en paralelo.

¿Qué debe hacer un comité directivo en un programa SAP?

Tomar decisiones. Su trabajo es resolver lo que el equipo del programa no puede: conflictos de recursos, disputas de alcance, cambios de presupuesto y todo lo que requiera autoridad transversal. Una reunión del comité directivo que termina sin decisiones fue una puesta al día.

Un comité directivo mensual en un programa grande deja los problemas esperando hasta cuatro semanas. Quincenal es el mínimo en plena ejecución, y semanal en cutover y hypercare. Envíe los informes de avance con antelación y use la reunión para las decisiones que plantean.