Cómo empezar bien su proyecto de implementación de SAP

Para empezar bien una implementación de SAP, hay que dejar cinco cosas resueltas antes de que nadie configure una transacción. Elegir el modelo de despliegue. Firmar un charter con alcance y derechos de decisión. Nombrar responsables de negocio que asistan a los talleres de diseño. Empezar pronto con los datos y el cutover. Construir un calendario con una contingencia real. Si esto queda bien en el primer mes, la mayoría de los fallos costosos no llegan a ocurrir.

Siempre pensé que, si el sistema estaba bien configurado, una implementación de SAP saldría adelante sin problemas. Blueprint, construcción, pruebas, go-live. Ese fue el modelo mental que seguí durante años.

Llevo 25 años implementando ERP, SAP incluido, en Oriente Medio, el Sudeste Asiático y Europa. Incluso cuando los equipos siguieron SAP Activate paso a paso, los proyectos se toparon con problemas. Casi nunca eran técnicos. Una apropiación débil del proyecto. Supuestos que nadie comprobó. Una planificación del cutover que empezó demasiado tarde. Estas grietas parecen inofensivas al principio. Cuando se extienden, el esfuerzo de última hora no puede arreglar lo que una visibilidad temprana habría evitado.

Una implementación de SAP es un programa de cambio de negocio con un componente de software. Los frentes de trabajo son el diseño de procesos, la configuración, la migración de datos, la integración, las pruebas, la formación y la gestión del cambio. Cada uno tiene su propio calendario, sus riesgos y su responsable.

Los equipos que la tratan como un ejercicio de configuración subfinancian todo lo que no es configuración. Es la causa más constante de los go-lives difíciles que veo.

Para un programa que arranca hoy hay un frente más que definir primero: el modelo de despliegue. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) u on-premise. Esa elección determina cómo funcionan todos los demás frentes.

SAP Activate es el método de entrega de SAP. Tiene seis fases, cada una con puertas de calidad al final. Esto es para lo que sirve cada fase y lo único que yo no dejaría pasar.

Fase	Qué ocurre	Lo que me aseguro de que esté bien
Discover	Caso de negocio, alcance de alto nivel, modelo de despliegue	Un costo y un calendario realistas, no los optimistas
Prepare	Gobierno, charter, equipo, registro de riesgos, entornos	Responsables de decisión con nombre y autoridad real
Explore	Talleres de fit-to-standard, decisiones sobre brechas, aprobación del diseño	El negocio en la sala, no solo TI
Realize	Configuración, desarrollo, integración, pruebas del sistema	La planificación del cutover ya en marcha
Deploy	Pruebas de aceptación de usuario, cargas de datos, formación, cutover	Al menos un ensayo general completo
Run	Go-live, hypercare, traspaso a soporte	Hypercare con personal asignado hasta el primer cierre mensual

El fallo de calendario más habitual es un Explore lento. Comprime Realize, que a su vez comprime Deploy. Se acortan las pruebas de aceptación de usuario (UAT), se salta el ensayo de datos y el go-live se hace igualmente porque la fecha ya se había anunciado. Los primeros 90 días tras el go-live lo pagan.

1. 01Explore se retrasaEl fit-to-standard y la aprobación del diseño se desplazan
2. 02Realize se comprimeMenos tiempo para construir y probar
3. 03Deploy se comprimeMenos tiempo para UAT, cargas de datos y formación
4. 04Se recortan las pruebasSe acorta la UAT y se salta el ensayo de datos
5. 05Go-live en la fecha anunciadaPorque la fecha ya estaba anunciada

El costo recae en el hypercare, en los primeros 90 días

1. Aprobación del diseño sin el negocio

Explore produce un diseño. Su calidad depende de si los responsables de proceso que lo firmaron entendieron lo que firmaban. Cuando a los talleres solo asisten TI y los consultores, el diseño puede ser técnicamente correcto y aun así resultar irreconocible para quienes lo van a usar. Entonces la UAT se convierte en descubrimiento en lugar de validación.

Una prueba sencilla: tres meses después de la aprobación, pida a un responsable de proceso que le explique cómo funcionará un pedido de compra tras el go-live. Si no puede, la aprobación no fue real.

2. Un gobierno que solo existe en el papel

Sin un gobierno que se haga cumplir, el alcance crece de manera informal y las decisiones se aplazan. Un buen gobierno significa un patrocinador ejecutivo con nombre, un comité directivo con derechos de decisión definidos, un director de proyecto capaz de sostener una puerta de fase y un proceso de control de cambios con un aprobador designado.

En la mayoría de mis proyectos, la CFO asumió el papel de impulsora del proyecto. Cuando los departamentos no lograban ponerse de acuerdo sobre un proceso, ella tomaba la decisión final. Eso evitó las semanas de retraso que se acumulan cuando los problemas quedan sin resolver. Mi guía sobre los comités directivos de SAP explica cómo montarlo.

3. Planificación tardía del cutover

El cutover es la parte más compleja del programa desde el punto de vista operativo. Un plan que arranca unas pocas semanas antes del go-live no se ensayará, pasará por alto dependencias y no tendrá un punto real de retroceso.

Empiece a planificar el cutover en Realize. Documente la secuencia, haga al menos un ensayo general completo y acuerde de antemano los criterios de retroceso. Las decisiones de cutover tomadas bajo presión, por personas que llevan veinte horas despiertas y sin criterios pactados, son donde empiezan los desastres posteriores al go-live.

4. Pruebas de integración recortadas

Sinceramente, antes pensaba que probar era una tarea más de una lista. Configurar el sistema, ejecutar unos cuantos casos de prueba, seguir adelante. Entonces vi cómo un proyecto se venía abajo solo porque nadie comprobó cómo afectaban las aprobaciones de compra a las contabilizaciones financieras. Ese momento cambió mi forma de ver las pruebas en SAP.

Las pruebas unitarias demuestran que una transacción funciona por sí sola. Los fallos que duelen después del go-live aparecen cuando un proceso completo atraviesa varios módulos. Una entrada de mercancías bloqueada por el estado de un pedido de compra. Una ejecución de facturación detenida por una determinación de cuentas que falta. Pruebe las cadenas completas, del pedido al cobro y de la compra al pago, y no deje que se desplacen a las últimas semanas antes de la UAT.

5. Migración de datos subestimada

Los datos de origen casi siempre están peor de lo que sugiere la primera evaluación. Los mapeos de campos que parecen sencillos fallan en la carga. Los recuentos de registros incluyen datos inactivos. Las reglas de limpieza requieren decisiones de negocio, y esas llevan tiempo.

Una empresa de manufactura descubrió miles de registros duplicados de clientes durante la migración y tuvo que retrasar el go-live tres semanas para corregirlos. Planifique ciclos de carga adicionales desde el principio. Mi artículo sobre por qué fracasa la migración de datos de SAP entra en el detalle.

6. La gestión del cambio tratada como algo opcional

He visto proyectos en los que el sistema funcionaba perfectamente y los usuarios seguían aferrados a los procesos antiguos. No porque fueran difíciles, sino porque nadie les acompañó en el cambio. Cuando se recorta la gestión del cambio, en la primera semana aparecen soluciones provisionales que se vuelven permanentes, y los tickets de soporte se mantienen altos durante meses.

La personalización excesiva entra en la misma categoría. Una vez trabajé con un cliente que personalizó más del 60 % del sistema. Tuvo dificultades para actualizar más tarde y perdió el soporte del proveedor.

Los fundamentos anteriores no han cambiado. Hay tres cosas que conviene dejar resueltas al inicio de un programa hoy.

El modelo de despliegue va primero. Public Edition ofrece las opciones de personalización más limitadas y SAP opera el sistema. Private Edition bajo RISE da más margen y SAP opera la infraestructura. On-premise da el mayor control y la mayor responsabilidad. Decídalo en Discover. Los programas que lo aplazan se pasan Explore discutiéndolo.

Clean Core pertenece al charter. Public Edition solo permite extensiones mediante interfaces liberadas, así que impone Clean Core de forma técnica. Private Edition y on-premise no lo hacen, por lo que pasa a ser una decisión de gobierno. SAP clasifica ahora las extensiones desde el nivel A (solo APIs liberadas) hasta el nivel D (modificaciones), como expone en su actualización sobre Clean Core de agosto de 2025. Escriba el nivel objetivo y el foro de aprobación en el charter, o los socios optarán por defecto por las modificaciones.

Las herramientas de IA pertenecen al método desde el primer día. Joule está disponible dentro del Roadmap Viewer de SAP Activate. Joule for consultants responde preguntas de configuración, y Joule for developers genera código ABAP Cloud. Pueden acelerar las tareas de redacción y de construcción. No eliminan las decisiones de negocio, el trabajo con los datos ni el esfuerzo de cambio. Pregunte a su socio dónde las usa y cómo se refleja eso en el plan.

El enfoque debe responder a su tolerancia al riesgo, a la complejidad y a la capacidad de absorber el cambio. Estas son las opciones habituales.

Enfoque	Qué significa	Más adecuado para
Big bang	Todos los módulos y entidades hacen go-live a la vez	Organizaciones pequeñas con alcance estándar, que aceptan un mayor riesgo en el go-live
Por fases, por módulo	Primero finanzas, luego cadena de suministro, luego RR. HH.	Módulos con pocas dependencias cruzadas; permite que el equipo aprenda entre fases
Por fases, por país o entidad	Una plantilla hace go-live en una entidad y después se despliega al resto	Grupos con una plantilla global
Conversión brownfield	El ECC existente se convierte a S/4HANA	ECC maduro con procesos estables
Greenfield	Nueva implementación de S/4HANA	Sistemas heredados que no son SAP, o ECC con mucha deuda técnica
Transición selectiva de datos	Entidades o datos elegidos se trasladan a un sistema rediseñado	Fusiones, escisiones, reutilización parcial

He visto despliegues pequeños hacer go-live en menos de seis meses. También he visto proyectos arrastrarse durante dos años porque las decisiones no se tomaron a tiempo. Si está sopesando una primera implementación frente a un despliegue de plantilla, mi guía de implementación frente a despliegue las compara.

Úsela en el primer mes, antes de que empiece la configuración. Cada punto tiene un responsable del lado del cliente.

1. Patrocinador ejecutivo: modelo de despliegue decidido y registrado, con sus motivos.
2. Director del programa: charter firmado, que cubra alcance, exclusiones explícitas, criterios de éxito, derechos de decisión y control de cambios. Los acuerdos verbales de alcance se evaporan. Mi guía del project charter incluye una plantilla.
3. Líderes de negocio: un responsable de proceso con nombre por área, con tiempo realmente liberado para asistir a los talleres.
4. Arquitecto de soluciones: objetivo de Clean Core y foro de aprobación de extensiones acordados.
5. Responsable de datos: perfilado de datos iniciado en Prepare, no después de la aprobación del diseño.
6. Responsable de cutover: designado en Realize, con una fecha de ensayo ya incluida en el plan.
7. Responsable de pruebas: escenarios de prueba de cadenas de proceso completas ya listados, incluidas las aprobaciones hasta las contabilizaciones financieras.
8. CFO: calendario contrastado con programas comparables, con contingencia para un Explore lento y para ciclos de datos adicionales. Un plan que supone que todo sale bien no es un plan.

¿Qué es un proyecto de implementación de SAP?

Es el programa que pone en marcha el software de SAP para operar la actividad de una empresa. Abarca el diseño de procesos, la configuración, la migración de datos, la integración, las pruebas, la formación y la gestión del cambio, y suele ejecutarse con SAP Activate. El esfuerzo varía enormemente según el número de entidades, países y módulos, y según el estado de sus datos actuales.

¿Cuáles son las fases de una implementación de SAP?

SAP Activate tiene seis fases: Discover, Prepare, Explore, Realize, Deploy y Run. Discover fija el caso de negocio y el alcance. Prepare establece el gobierno y el equipo. Explore realiza los talleres de fit-to-standard y confirma el diseño. Realize construye y prueba. Deploy abarca la UAT, las cargas de datos, la formación y el cutover. Run es el go-live y el hypercare. Cada fase termina con una puerta de calidad.

¿Cuánto dura una implementación de SAP?

Depende del alcance y de la rapidez con que se tomen las decisiones. He visto despliegues pequeños hacer go-live en menos de seis meses, y proyectos que se arrastraron durante dos años porque las decisiones no se tomaron a tiempo. La causa más común de desviación es una fase Explore lenta que comprime todo lo que viene después.

¿Cuáles son los motivos más habituales por los que fracasan las implementaciones de SAP?

Un diseño aprobado sin una implicación real del negocio, un gobierno que no se hace cumplir, una planificación tardía del cutover, unas pruebas de integración comprimidas, una migración de datos subestimada y una gestión del cambio recortada. Los seis suelen ser visibles pronto y baratos de corregir en ese momento.

¿Qué debe incluir el charter de un proyecto SAP?

Objetivos ligados a resultados medibles, alcance por módulo, entidad, país e integración, exclusiones explícitas, derechos de decisión con personas designadas, gobierno y escalado, criterios de éxito, control de cambios, hitos principales y supuestos clave. En un programa en la nube, añada el modelo de despliegue y el enfoque de Clean Core. Que lo firmen el patrocinador y los líderes de negocio antes de que empiece la configuración.

¿Qué es el hypercare tras el go-live de SAP?

El hypercare es el periodo de soporte intensivo posterior al go-live, normalmente de 30 a 90 días. El equipo del proyecto y el negocio trabajan codo con codo para resolver incidencias y estabilizar las operaciones. Manténgalo con personal asignado durante al menos un ciclo de negocio completo, incluido el primer cierre mensual, porque es cuando muchos problemas aparecen por primera vez.