Cronograma de implementación de SAP: duración de fases y 5 errores

Según mi experiencia, una implementación de SAP lleva de 6 a 9 meses con GROW with SAP y de 9 a 18 meses con RISE with SAP. Salir de SAP ECC lleva de 12 a 18 meses con una conversión brownfield o una transición selectiva de datos, y de 18 a 24 meses con una implementación greenfield.

Respuesta corta: cierre la fecha al final de Explore, no en el arranque, y añada un margen del 15 al 20 por ciento sobre la estimación del proveedor. Empiece el trabajo con los datos en Discover, porque la migración de datos supone entre el 30 y el 40 por ciento del esfuerzo de implementación. Cada mes adicional de retraso cuesta al menos seis cifras solo en honorarios de consultoría.

Esta guía es para directores de programa y patrocinadores que están armando un plan o rescatando uno. Trata del cuánto, no del cómo: para saber qué hace cada fase y quién la lleva, lea mi guía paso a paso de la implementación de SAP.

En un programa de fabricación en Europa en 2024, conocí a un jefe de proyecto cuyo proyecto SAP iba seis meses retrasado. Tras reorganizarse de forma estricta según las fases de SAP Activate, terminaron el trabajo pendiente en cuatro meses.

En sus palabras: «Tener fases claras con entregables concretos lo cambió todo. Siempre sabíamos exactamente qué teníamos que hacer a continuación».

El modelo de despliegue cambia el cronograma de implementación de SAP más que cualquier otra decisión. Estos son los rangos con los que planifico:

Punto de partida y destino	Plazo típico	Qué marca el ritmo
GROW with SAP (SAP Cloud ERP, edición pública)	6 a 9 meses	Solo procesos estándar; extensiones sobre API publicadas
RISE with SAP (SAP Cloud ERP Private)	9 a 18 meses	Alcance, número de extensiones, volumen de datos
Conversión brownfield desde ECC	12 a 18 meses	Código a medida, simplification items, pruebas
Implementación greenfield desde ECC	18 a 24 meses	Rediseño de procesos, carga de cambio para los usuarios
Transición selectiva de datos	12 a 18 meses	Delimitación de los datos y herramientas especializadas

Como referencia, un experto de producto de SAP que revisó cientos de proyectos de la edición pública sitúa la salida en vivo típica en cinco a siete meses. La oferta GROW Fast de SAP, lanzada a principios de 2026, apunta a dos a cuatro meses con un alcance fijo. Yo planifico los programas GROW en 6 a 9 meses porque los datos, las decisiones y la formación consumen el tiempo que el software no consume.

En RISE, SAP gestiona la infraestructura, lo que elimina parte del trabajo de Prepare. No elimina el esfuerzo de datos, de pruebas ni de gestión del cambio. La guía de migración de ECC a S/4HANA explica cómo elegir entre brownfield, greenfield y selectivo.

SAP Concur, el producto de viajes y gastos, es un producto cloud independiente con su propio proyecto. Planifíquelo como un frente de trabajo aparte con su propia integración con las finanzas de S/4HANA, no dentro del plan de fases de S/4HANA.

Dónde se rompen los presupuestos y las fechas

El mayor error que veo es no planificar bien al principio. Las fechas y los presupuestos se desbordan en Explore, cuando crece la lista de workflows, informes, interfaces, conversiones, mejoras y formularios (WRICEF) y es el proveedor, no el cliente, quien controla el alcance.

Mi desglose de costos de la implementación de SAP muestra cómo eso puede convertirse en un desvío del 50 por ciento. Los cronogramas que se cumplen comparten tres cosas: márgenes realistas, supuestos validados antes de cerrar el plan y puntos de control de calidad tratados como paradas obligatorias.

Cinco errores explican la mayoría de los desvíos. Cada uno es previsible, y cada uno tiene su contramedida.

Error 1: fijar plazos antes de entender el alcance

En un programa de retail en el CCG en 2023, el cliente prometió a su consejo de administración una implementación en nueve meses sin margen. Cuando la migración de datos llevó más de lo previsto, incumplieron el plazo por tres meses y la dirección perdió la confianza en el equipo. Se lo dije sin rodeos: ese cronograma era demasiado agresivo.

La solución: cierre el cronograma después de Explore, no en el arranque, y dígaselo al consejo desde el principio. Incluya un margen del 15 al 20 por ciento sobre la estimación del proveedor.

Error 2: tratar la migración de datos como un frente que empieza tarde

La mayoría de los equipos nombra tarde al responsable de migración de datos y dota el trabajo con pocos recursos. Las primeras evaluaciones de datos casi siempre subestiman el problema, y vienen tres meses de limpieza bajo la presión de un sistema en producción.

La solución: empiece el perfilado de datos en Discover, no en Realize. Haga una migración de prueba completa en Realize antes de que empiecen las pruebas de integración. Mi artículo sobre por qué fracasan las migraciones de datos de SAP explica en detalle el ciclo de migraciones de prueba.

Error 3: saltarse los puntos de control de calidad por presión de plazos

El punto de control entre Realize y Deploy es el que los equipos se saltan con más frecuencia, porque la presión por «salir en vivo de una vez» llega a su máximo ahí. Saltarse los puntos de control de calidad para «cumplir el calendario» causa retrasos mayores después.

La solución: incluya criterios de salida medibles en el acta de constitución del proyecto y deje que el comité directivo los haga cumplir. Uso un ensayo de cierre de tres días como punto de control de preparación en todos los programas. Encontrará más sobre el diseño de estos puntos de control en mi guía de quality gates de SAP.

Error 4: formar a los usuarios dos meses antes de la salida en vivo

En un programa de retail en el CCG en 2024, el cliente formó a todos sus usuarios dos meses antes de la salida en vivo. El día del lanzamiento, la mayoría había olvidado cómo usar el sistema. Pusimos guías rápidas en cada puesto de trabajo y duplicamos el soporte en planta.

La solución: programe la formación dos a tres semanas antes de la salida en vivo y use a los usuarios clave como formadores, porque la gente aprende de los compañeros en quienes confía. Mi artículo sobre estrategias de formación en SAP recoge el enfoque completo.

Error 5: programar la salida en vivo en los picos del negocio

Hershey salió en vivo con su sistema de SAP R/3, Siebel y Manugistics en julio de 1999, tres meses más tarde de lo previsto y en plena temporada de pedidos de Halloween. Su CEO dijo a los analistas que los problemas impedirían a Hershey entregar 100 millones de dólares en pedidos de Halloween.

La solución: identifique los picos de cada unidad de negocio afectada, incluidos los cierres de mes y de trimestre. Salga en vivo en una ventana de bajo volumen aunque suponga moverlo seis semanas. Ese movimiento se recupera, pero una salida en vivo fallida en temporada alta no.

SAP Activate tiene seis fases, y son el esqueleto de cualquier plan de S/4HANA, en la nube u on-premise. Las duraciones siguientes son puntos de partida para planificar un único programa, no promesas.

1. 1Discover2 a 4 semanas. Salida: alcance firmado y criterios de éxito
2. 2Prepare3 a 6 semanas. Salida: acta aprobada, recursos comprometidos por escrito
3. 3Explore4 a 8 semanas. Salida: decisiones sobre brechas con responsable, cronograma cerrado
4. 4Realize8 a 16 semanas. Salida: migración de prueba superada, pruebas de integración cerradas
5. 5Deploy2 a 4 semanas. Salida: aprobación de UAT, ensayo de cierre, go/no-go
6. 6Run4 a 8 semanas de hypercare. Salida: defectos por debajo del umbral, traspaso a soporte firmado

Esta es la tabla de fases con la que empiezo todos los planes:

Fase	Duración típica	Qué ocurre	Punto de control de salida antes de avanzar
Discover	2 a 4 semanas	Caso de negocio, alcance, elección del modelo de despliegue (nube pública, nube privada u on-premise)	Alcance firmado y criterios de éxito medibles
Prepare	3 a 6 semanas	Incorporación del equipo, gobierno, panorama de sistemas, plan base, registro de riesgos	Acta aprobada, responsables de decisión nombrados por módulo, compromisos de recursos por escrito
Explore	4 a 8 semanas	Talleres Fit-to-Standard, registro de brechas, inventario WRICEF	Decisiones sobre brechas registradas con responsables; cronograma cerrado
Realize	8 a 16 semanas	Configuración, desarrollo, pruebas unitarias y de integración, migraciones de prueba	Migración de prueba superada; pruebas de integración cerradas
Deploy	2 a 4 semanas	Pruebas de aceptación de usuarios, ensayo del cutover, formación de usuarios finales, carga final	Aprobación de UAT, ensayo de cierre superado, go/no-go
Run	4 a 8 semanas de hypercare	Soporte en planta, triaje diario, traspaso a soporte	Defectos abiertos por debajo del umbral acordado; transición a soporte firmada

Adónde se va realmente el tiempo

Discover se hace con prisas. Los equipos fijan una fecha antes de entender el alcance y se saltan criterios de éxito medibles, como «reducir el cierre mensual en tres días».

Prepare es donde empiezan los retrasos técnicos en on-premise, porque el cliente y el socio montan la infraestructura. Consiga los compromisos de recursos por escrito. La disponibilidad verbal se evapora.

Explore es donde importa dejar constancia. Seis meses después nadie recuerda por qué las devoluciones se gestionan de cierta manera, salvo que la decisión y su responsable se hayan puesto por escrito.

Realize es la fase más larga y donde acaban la mayoría de los desvíos, normalmente porque Explore produjo una lista de brechas optimista. Su primera migración de prueba fallará, y necesita que falle en pruebas, no en producción.

Deploy necesita un plan de cutover con pasos, horas y responsables exactos. «Migrar los datos» no es un paso.

En un programa del sector salud en Estados Unidos en 2023, el cliente iba tres meses retrasado y se enfrentaba a un sobrecosto de 2 millones de dólares. Reorganizamos el proyecto con los talleres Fit-to-Standard de SAP Activate. El equipo encontró 28 procesos que podía operar sin ninguna personalización.

En palabras de su jefe de proyecto: «Perdimos meses diseñando cosas que SAP ya tenía construidas». En seis semanas volvieron a estar dentro del calendario.

En un programa de retail en Europa en 2024, el cliente descubrió que el 70 por ciento de sus necesidades quedaba cubierto por procesos estándar de SAP. Había planificado personalizaciones extensas hasta que vio el sistema en funcionamiento.

El clean core lo hace aún más evidente. En la edición pública, los procesos estándar son la única opción y las extensiones se sitúan en SAP BTP o sobre API publicadas. En la edición privada y on-premise todavía se puede modificar, pero cuando cada brecha exige una decisión de extensión con un costo asociado, la conversación sobre personalizaciones se vuelve más honesta.

Cada sector añade su propio lastre. Estos rangos cubren un programa empresarial completo de S/4HANA con varias sedes, por eso son más largos que un único despliegue RISE de 9 a 18 meses:

Sector	Rango de planificación	Qué alarga el plazo
Fabricación	14 a 20 meses	Calidad de listas de materiales y hojas de ruta, ajuste del MRP, requisitos de QM
Retail y bienes de consumo	12 a 18 meses	Integración del punto de venta (POS), volumen de datos maestros, ventanas de temporada alta
Farmacéutica	16 a 22 meses	Validación GxP, trazabilidad de lotes, serialización
Servicios públicos (utilities)	15 a 20 meses	Gestión de dispositivos, estructuras tarifarias de facturación, integración con GIS y SCADA
Sector público	18 a 24 meses	Contabilidad presupuestaria, normativa de contratación, carga de aprobaciones, residencia de datos
Automoción	16 a 22 meses	Cadena de suministro just-in-time, control de cambios de ingeniería
Aeroespacial y defensa	20 a 26 meses	Informes para el gobierno, contabilidad por programas, cadenas de suministro seguras
Petróleo y gas	18 a 24 meses	Contabilidad de joint ventures, operaciones intensivas en activos
Servicios financieros	14 a 20 meses	Diseño de roles con segregación de funciones, validación regulatoria

Qué cambian las herramientas de IA y qué no

SAP Joule for Consultants llegó a disponibilidad general en 2025. Responde preguntas de configuración a partir de la propia base de conocimiento de SAP, incluidas las SAP Notes, y explica código ABAP. SAP Build Code, disponible de forma general desde marzo de 2024, genera con Joule código de extensiones en Java y JavaScript sobre SAP BTP.

Ambas ayudan a consultores y desarrolladores individuales. Ninguna cambia lo que tardan los talleres, las decisiones, la limpieza de datos o la aceptación de usuarios. Planifique con ellas, pero no quite semanas del plan hasta que su propio equipo haya medido el efecto.

Estos son los riesgos que pongo en la agenda semanal del programa. Cada uno mueve fechas si se deja para el comité directivo mensual.

1. Cambios de alcance tardíos. Cierre el alcance al final de Explore. A partir de ahí, un comité de control de cambios aprueba cada cambio con su impacto en el cronograma y el presupuesto.
2. Calidad de los datos. La mayoría de las empresas se salta la evaluación de datos durante la planificación. Los datos de mala calidad son la causa más constante de migraciones de prueba fallidas.
3. Cuellos de botella de recursos. Consiga compromisos por escrito de los jefes de departamento para personas y fechas concretas. Forme un suplente para cada rol crítico.
4. Retrasos en las decisiones. Escale los desacuerdos de alcance en un plazo de 48 horas. No deje que las decisiones se acumulen para las revisiones mensuales.
5. Gestión del cambio tardía. Empiece a hablar con los usuarios finales en Prepare, no dos semanas antes de la salida en vivo.

En cuanto a herramientas, SAP Cloud ALM es la plataforma de SAP para gestionar la implementación. El mantenimiento estándar de SAP Solution Manager 7.2 termina a finales de 2027, con mantenimiento extendido para funciones seleccionadas hasta 2030. SAP Best Practices Explorer se retiró en 2023, y su contenido de procesos está ahora en SAP Signavio Process Navigator.

Esta guía forma parte de mi guía central de implantación de SAP, que enlaza todos los temas, desde el caso de negocio hasta la puesta en marcha.

¿Cuánto tarda una implementación de SAP S/4HANA?

Según mi experiencia, de 6 a 9 meses con GROW with SAP (edición pública) y de 9 a 18 meses con RISE with SAP (edición privada). Desde ECC, una conversión brownfield o una transición selectiva de datos lleva de 12 a 18 meses, y una implementación greenfield de 18 a 24 meses.

¿Cuánto dura cada fase de SAP Activate?

Como punto de partida para planificar: Discover 2 a 4 semanas, Prepare 3 a 6 semanas, Explore 4 a 8 semanas, Realize 8 a 16 semanas, Deploy 2 a 4 semanas y Run 4 a 8 semanas de hypercare. Realize es la que más se alarga en los programas grandes.

¿Cómo afecta RISE with SAP al cronograma?

RISE traslada a SAP la responsabilidad de la infraestructura, lo que elimina parte del trabajo de la fase Prepare. No acorta la migración de datos, las pruebas, la formación ni la toma de decisiones, que es donde se va la mayor parte del tiempo. La disciplina de clean core puede acortar Realize si frena el desarrollo a medida antes de que empiece.

¿Cuánto margen debe incluir el cronograma de una implementación de SAP?

Incluya un margen del 15 al 20 por ciento sobre la estimación del proveedor. Cierre la fecha al final de Explore, cuando se conocen el alcance y las brechas, y dígaselo al consejo antes del arranque.

¿Cómo puedo acortar el cronograma de una implementación de SAP?

Aplique Fit-to-Standard con rigor, porque cada personalización que evita ahorra semanas. Empiece la limpieza de datos en Discover y dedique recursos del negocio a tiempo completo en lugar de tomarlos prestados a tiempo parcial. Prepare el plan de cutover durante Realize y no después.

¿Debo elegir un despliegue de SAP big bang o por fases?

El big bang pone todo en vivo a la vez. Es más rápido en conjunto y más arriesgado, y encaja con un alcance más reducido o con organizaciones con una gestión del cambio sólida. El despliegue por fases avanza por módulo, sede o unidad de negocio, tiene menos riesgo y dura más, y encaja con grandes grupos con muchas sociedades.

¿Cuáles son las causas más comunes de retraso en los proyectos SAP?

Solicitudes de cambio sin control, sorpresas en la calidad de los datos, gestión del cambio tardía, fallos de integración con terceros, la pérdida de personas clave a mitad de proyecto y decisiones lentas del comité directivo. La que más sorprende a los equipos es la calidad de los datos. Todo el mundo da por hecho que los datos heredados están limpios, y casi nunca lo están.

¿Cuánto dura el hypercare después de la salida en vivo de SAP?

Planifique de cuatro a ocho semanas de hypercare: soporte en planta, triaje diario de incidencias y monitorización del rendimiento. Después, el sistema pasa a un equipo de soporte de aplicaciones o a un centro de excelencia interno.