Noel D'Costa
Contenido
- Qué abarca una implementación de SAP
- Pasos de la implementación de SAP: las seis fases de SAP Activate
- ¿Cinco etapas o seis?
- El punto de control del ensayo de cierre de tres días
- Planificar antes de empezar a configurar
- Mapear los procesos actuales tal como funcionan de verdad
- Decidir estándar o extensión para cada proceso
- Auditar la calidad de los datos antes de la migración
- Formar primero el equipo y después cerrar el alcance
- A quién necesita en un proyecto de implementación de SAP
- Retos habituales y qué hacer con ellos
- Antes, durante y después de la salida en vivo
- Dos programas que funcionaron
- Qué ha cambiado para los programas que empiezan ahora
- Las ediciones cloud son la opción por defecto
- El clean core se gradúa, no es binario
- La IA en el equipo de entrega
- Preguntas frecuentes
La implementación de SAP es el programa que lleva las finanzas, las compras, la cadena de suministro, las ventas y los recursos humanos de una empresa a un único sistema SAP, hoy normalmente SAP S/4HANA. Recorre las seis fases de SAP Activate (Discover, Prepare, Explore, Realize, Deploy y Run), y su éxito o fracaso depende del trabajo sobre procesos, datos y personas que se haga antes de que nadie configure nada.
Respuesta corta: un proyecto de implementación de SAP sustituye sistemas heredados separados por un solo sistema y un solo modelo de datos. El proceso tiene seis pasos: confirmar el caso de negocio, movilizar al equipo, diseñar sobre el estándar de SAP, construir y probar, salir en vivo, y después estabilizar y traspasar. Según mi experiencia, lleva de 6 a 9 meses con GROW with SAP y de 9 a 18 meses con RISE with SAP, y mi guía del cronograma de implementación de SAP lo desglosa fase por fase.
En los 21 programas SAP que he dirigido, rescatado o visto torcerse, el patrón se repite. A las empresas que tratan SAP como una instalación de software les cuesta. Las que rediseñan primero los procesos y configuran después entregan lo que prometieron al consejo de administración.
Esta guía es para directivos y responsables de programa a punto de empezar uno. Si solo lee una sección, lea «Planificar antes de empezar a configurar».
S/4HANA es el ERP actual de SAP y funciona sobre la base de datos en memoria SAP HANA. Muchas empresas todavía usan el antiguo SAP ECC, pero el mantenimiento estándar de ECC termina el 31 de diciembre de 2027, con un mantenimiento extendido opcional hasta finales de 2030 a una tarifa más alta.
Estos son los módulos principales que la mayoría de las implementaciones abordan primero:
| Módulo | Qué gestiona |
|---|---|
| FI (contabilidad financiera) | Libro mayor, cuentas por pagar, cuentas por cobrar, contabilidad de activos fijos |
| CO (controlling) | Centros de costo, centros de beneficio, órdenes internas, informes de gestión |
| MM (gestión de materiales) | Compras, inventario, movimientos de mercancías, gestión de proveedores |
| SD (ventas y distribución) | Order-to-cash, precios, expedición, facturación |
| PP (planificación de la producción) | Órdenes de fabricación, planificación de capacidad, MRP |
| HCM (gestión del capital humano) | Datos maestros de RR. HH., nómina, gestión de tiempos |
La mayoría de las empresas empieza con FI/CO y uno o dos módulos operativos. El resto se construye en versiones posteriores.
Una implementación no es lo mismo que una migración. Si ya usa SAP ECC, está convirtiendo o reconstruyendo un sistema SAP, y mi guía de migración de ECC a S/4HANA cubre las vías greenfield, brownfield y selectiva.
SAP Activate es la metodología de implementación de SAP. Sustituyó al antiguo método ASAP y tiene seis fases, cada una con un punto de control que hay que superar antes de avanzar.
Las seis fases de SAP Activate
Discover
Confirmar el caso de negocio y probar los procesos prioritarios en un sistema de prueba o de demostración.
Prepare
Movilizar: equipo, gobierno, documento de alcance, plan y acceso a los sistemas.
Explore
Talleres Fit-to-Standard con los dueños de procesos. Construir el backlog de configuración, integraciones y extensiones.
Realize
Configurar, extender, migrar datos y probar. La fase más larga. Para salir hace falta una ejecución de regresión limpia.
Deploy
Formar a los usuarios con procesos reales, ensayar el cutover y salir en vivo con una sala de crisis preparada.
Run
Hypercare, optimización y traspaso al centro de excelencia.
Esta tabla es la versión que cuelgo en la pared de la oficina del programa. Muestra qué debe producir cada fase, quién es responsable y qué tiene que cumplirse antes de que empiece la siguiente.
| Fase | Debe producir | Responsable | Condición para avanzar |
|---|---|---|---|
| Discover | Caso de negocio, alcance objetivo, elección del modelo de despliegue | Patrocinador y CFO | Financiación aprobada |
| Prepare | Documento de alcance, plan, gobierno, equipo formado | Director del programa | El patrocinador firma el alcance |
| Explore | Resultados de Fit-to-Standard, backlog, decisiones sobre extensiones | Arquitecto de soluciones con los dueños de procesos | Ninguna brecha sin resolver |
| Realize | Sistema configurado y probado, datos de prueba migrados | Responsables funcionales y técnicos | Ejecución de regresión limpia; los datos cuadran |
| Deploy | Usuarios formados, cutover ensayado, paquete go/no-go | Responsable del cutover | Ensayo de cierre de tres días superado |
| Run | Registro de hypercare, traspaso al CoE, backlog de la fase 2 | Responsable de prestación del servicio | Ningún P1/P2 abierto; el CoE acepta |
Las plantillas de cada fase están en mi guía de plantillas de SAP Activate.
¿Cinco etapas o seis?
Mucha gente busca las «5 etapas de la implementación de SAP» porque el antiguo método ASAP de SAP tenía cinco fases. Eran preparación del proyecto, Business Blueprint, realización, preparación final, y salida en vivo y soporte.
SAP Activate mantiene la misma lógica y añade Discover al principio y Run al final. De Prepare a Deploy se suelen considerar las fases centrales de entrega. Los equipos que todavía dicen «blueprint» suelen referirse a Explore.
El punto de control del ensayo de cierre de tres días
El punto de control entre Realize y Deploy es el que los equipos se saltan con más frecuencia bajo presión de plazos. Uso un ensayo de cierre de tres días como punto de control de preparación en todos los programas. Si finanzas no puede cerrar los libros en el nuevo sistema, su migración de datos no está lista, diga lo que diga TI.
Saltarse ese punto de control cuesta más que el retraso que habría causado.
El orden importa. Hay que hacer cuatro cosas antes de tomar una sola decisión de configuración.
- Mapear los procesos actualesTal como funcionan de verdad, con sus soluciones improvisadas
- Decidir estándar o extensiónEl estándar casi siempre es más rápido
- Auditar la calidad de los datosAntes de que empiece la migración de datos
- Formar el equipo y después fijar el alcanceQuién está disponible decide lo que puede entregar
Solo entonces empieza la configuración
El mayor error que veo es no planificar bien al principio. 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 lo que eso le hace al presupuesto.
Mapear los procesos actuales tal como funcionan de verdad
No lo que el proceso debería ser. Lo que realmente es, con sus soluciones improvisadas.
En un programa de servicios financieros en Europa en 2023, estuve en una sesión de blueprint en la que finanzas conciliaba transacciones entre empresas del grupo en hojas de cálculo. En esas soluciones improvisadas se esconden los requisitos que nadie ha puesto por escrito.
Decidir estándar o extensión para cada proceso
Identifique qué procesos cubre la funcionalidad estándar de SAP y cuáles necesitan una extensión. El estándar casi siempre es más rápido, porque cada extensión añade ciclos de prueba, riesgo en las actualizaciones y mantenimiento.
Con las pautas de clean core de SAP, además, cada extensión tiene que ubicarse en un lugar elegido a conciencia. Eso hace que la decisión tenga más consecuencias, no menos.
Auditar la calidad de los datos antes de la migración
Los datos son el frente de trabajo más subestimado. Según mi experiencia, la migración de datos supone entre el 30 y el 40 por ciento del esfuerzo de implementación.
Un cliente tenía más de 18.000 registros de clientes duplicados. Corregirlo después de la salida en vivo alteró la facturación durante semanas. Perfile los datos pronto y límpielos en el sistema de origen; mi guía sobre por qué fracasan las migraciones de datos de SAP explica cómo.
Formar primero el equipo y después cerrar el alcance
El alcance que puede entregar depende de quién esté disponible para configurar, probar y asumir cada frente de trabajo. Los equipos que fijan primero el alcance y buscan personal después pasan meses rehaciendo lo que comprometieron de más.
Un proyecto de implementación de SAP necesita personas con nombre y apellido en estos roles, la mayoría de su lado, no del lado del socio:
- Patrocinador ejecutivo. Es dueño del caso de negocio y desempata. Normalmente el CFO o el COO.
- Director del programa. Lleva el plan, el presupuesto y el comité directivo. En su nómina o independiente del socio.
- Dueños de procesos. Uno por área (finanzas, compras, ventas, producción). Aprueban el diseño y son responsables del resultado después de la salida en vivo.
- Arquitecto de soluciones. Mantiene el diseño global y decide dónde vive cada extensión.
- Responsables funcionales y técnicos. Configuran, construyen y prueban. Normalmente el equipo del socio.
- Responsable de migración de datos. Nombrado en Prepare, no en Realize.
- Responsable de gestión del cambio y formación. Empieza a hablar con los usuarios finales en Explore.
- Responsable del cutover. Es dueño del runbook de la salida en vivo y del paquete go/no-go.
Hay una regla que importa más que la lista. El socio que va a hacer el trabajo no debería redactar su caso de negocio.
Su incentivo es empezar. El suyo es terminar.
SAP no arreglará procesos rotos. Los dejará al descubierto. Las empresas que más provecho sacan de SAP rediseñan primero sus procesos y configuran el sistema después.
Estos son los retos que veo en casi todos los programas, con la contramedida para cada uno:
| Reto | Cómo se manifiesta | Qué hacer |
|---|---|---|
| Ampliación descontrolada del alcance | Se acumulan peticiones del tipo «ya que estamos, añadan...» | Control formal de cambios desde el primer día; cada petición recibe una evaluación de impacto |
| Calidad de los datos | La migración revela incoherencias que nadie sabía que existían | Perfilar los datos pronto; limpiar en el sistema de origen |
| Resistencia de los usuarios | Los usuarios vuelven a Excel en las dos semanas siguientes a la salida en vivo | Implicar a los usuarios finales en el diseño desde Explore |
| Fallos de integración | Las conexiones con terceros fallan en las UAT | Mapear las interfaces en Explore; probar pronto con volúmenes realistas |
| Ciclos de prueba recortados | Se acorta la regresión para llegar a una fecha | Proteger las fases de prueba; un retraso en la construcción no debe comprimir las pruebas |
| Fatiga del equipo | El ánimo cae y las tasas de defectos suben en el tramo final | Seguirlo con un índice semanal de ánimo sencillo |
Sobre la fatiga del equipo, sigo un índice semanal de ánimo muy básico. Cuando más del 25 por ciento del equipo dice sentirse desbordado, las tasas de defectos en las pruebas se disparan.
En un programa de fabricación en el CCG en 2024, el equipo se saltó las pruebas de regresión para recuperar tres semanas de calendario. Después finanzas no pudo conciliar informes clave, y siguieron meses de limpieza. No fue un fallo del sistema, solo una decisión evitable.
Antes, durante y después de la salida en vivo
Antes de la salida en vivo, haga el ensayo de cierre, valide los datos migrados con informes de conciliación y forme con procesos reales en lugar de escenarios de demostración. Pruebe el plan de marcha atrás. Repase con el comité directivo los criterios go/no-go y obtenga una aprobación explícita, no asentimientos implícitos.
Durante la salida en vivo, intensifique la monitorización y mantenga al equipo de cutover disponible las 24 horas durante las primeras 72 horas. Las decisiones que se toman en esas horas deciden si el hypercare arranca con confianza o con una cola.
Después de la salida en vivo, mantenga el hypercare al menos cuatro semanas y siga los tickets de soporte por categoría. Le dirán dónde falló la formación y dónde hay que ajustar la configuración.
En un programa de fabricación en Europa en 2024, el cliente se quedaba una y otra vez sin materias primas. Compras culpaba a los planificadores, y los planificadores culpaban a unas hojas de cálculo en las que nadie confiaba. Sustituimos ese esquema por S/4HANA y nos apoyamos mucho en SAP PP con una configuración de MRP bien hecha.
Los niveles de stock pasaron de las conjeturas a los datos en tiempo real, y los pedidos de compra se disparaban según la necesidad. En los primeros seis meses, las roturas de materias primas bajaron más del 50 por ciento. El resultado vino del rediseño de procesos que precedió a la configuración, porque PP sin ese trabajo de procesos habría producido respuestas equivocadas más deprisa.
En un programa de servicios profesionales en el Reino Unido en 2024, el problema era finanzas. El cierre mensual tardaba más de dos semanas y los informes se rehacían a mano. Desplegamos SAP Finance por etapas bajo un comité directivo muy implicado.
El cierre mensual bajó a poco más de una semana. El CFO me dijo que los números «parecían creíbles».
Una guía escrita para 2022 no sobrevive al contacto con un comprador de 2026. Hay tres cambios que deben incorporarse al diseño desde el arranque.
Las ediciones cloud son la opción por defecto
SAP vende ahora dos ediciones de ERP en la nube: SAP Cloud ERP (la edición pública, antes S/4HANA Cloud Public Edition) y SAP Cloud ERP Private (la edición privada). RISE with SAP combina la edición privada con operaciones gestionadas por SAP y un conjunto de herramientas que incluye SAP Signavio, SAP LeanIX y SAP Cloud ALM. GROW with SAP es el paquete para empresas medianas sobre la edición pública.
La decisión sobre la edición está ahora por encima de los viejos debates sobre el despliegue. Big bang o por fases, y greenfield, brownfield o selectivo, son decisiones que se toman dentro de la edición, no en su lugar.
El clean core se gradúa, no es binario
En agosto de 2025 SAP introdujo cuatro niveles de clean core, de la A a la D. El nivel A usa solo API publicadas y estables, ya sea en paralelo sobre SAP BTP o dentro del sistema con ABAP Cloud. El nivel B permite API clásicas que todavía se consideran limpias, el nivel C requiere medidas especiales y el nivel D no es limpio.
La edición pública solo permite extensiones de nivel A. La edición privada y on-premise permiten extensiones clásicas, así que allí la disciplina viene del gobierno, no de que la plataforma se lo impida. Decida el nivel y la ubicación de cada extensión en Explore, y nombre a una persona que pueda decir que no.
La IA en el equipo de entrega
Joule está ahora dentro del SAP Activate Roadmap Viewer y de SAP Cloud ALM, donde responde preguntas sobre las tareas y redacta contenido a partir de la metodología. SAP Build Code, disponible de forma general desde 2024, usa Joule para generar lógica de aplicación, modelos de datos y pruebas para extensiones en Java y JavaScript sobre SAP BTP. SAP ha añadido una ayuda similar de IA generativa para los desarrolladores ABAP.
Mi opinión: la IA en los programas SAP es real, pero la calidad de los datos decide su valor. Una documentación de procesos limpia y unos datos maestros limpios producen resultados útiles, mientras que los datos sucios producen ruido muy seguro de sí mismo. Nada de esto elimina la necesidad de una persona responsable de cada decisión.
Las fases siguen vigentes y el orden del trabajo sigue importando. Un programa que incorpora desde el arranque la decisión de edición, la disciplina en las extensiones y las nuevas herramientas las trata como restricciones de diseño. Uno que las ignora pasa sus tres primeros meses descubriendo qué ha cambiado, normalmente a través de las solicitudes de cambio del socio.
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.
¿Qué es la implementación de SAP en términos sencillos?
Es el proyecto de poner en marcha el software de SAP para gestionar los procesos centrales de una empresa, como finanzas, compras, ventas y recursos humanos, en un solo sistema con un solo modelo de datos. Abarca el diseño de procesos, la configuración, la migración de datos, las pruebas, la formación y la salida en vivo, normalmente siguiendo la metodología SAP Activate.
¿Cuáles son las 5 etapas de la implementación de SAP?
Las cinco etapas proceden del antiguo método ASAP de SAP: preparación del proyecto, Business Blueprint, realización, preparación final, y salida en vivo y soporte. SAP Activate sustituyó a ASAP y usa seis fases, añadiendo Discover al principio y Run al final.
¿Cuáles son las seis fases de SAP Activate?
Discover (caso de negocio y encaje), Prepare (equipo, gobierno, plan), Explore (talleres Fit-to-Standard y backlog), Realize (configurar, extender, migrar, probar), Deploy (formar, ensayar el cutover, salir en vivo) y Run (hypercare y traspaso al centro de excelencia).
¿Qué diferencia hay entre una implementación de SAP y una migración de SAP?
Una implementación pone SAP en marcha, normalmente para sustituir sistemas que no son de SAP o heredados. Una migración lleva un sistema SAP ECC existente a S/4HANA, mediante conversión (brownfield), una construcción nueva (greenfield) o una transición selectiva de datos. Ambas siguen las fases de SAP Activate.
¿Quién debe formar parte de un equipo de implementación de SAP?
Un patrocinador ejecutivo, un director del programa, dueños de procesos para cada área, un arquitecto de soluciones, responsables funcionales y técnicos, un responsable de migración de datos, un responsable de gestión del cambio y formación y un responsable del cutover. El patrocinador, los dueños de procesos y el responsable de datos deben ser de su lado, no del socio.
¿Cuáles son las razones más comunes por las que fracasan las implementaciones de SAP?
Tres causas de fondo aparecen en casi todos los programas con problemas. Se omite el trabajo de procesos, se ignora la calidad de los datos hasta el cutover y la gestión del cambio se reduce a formación.
Una causa más reciente es un socio que construye extensiones sin un plan de clean core. Eso deja una deuda que aflora en la primera actualización importante.
¿Cómo elijo el socio adecuado para la implementación de SAP?
Busque experiencia en su sector y a su escala, con referencias a las que pueda llamar de verdad. La persona que hace la presentación comercial debería dirigir el programa. Pregunte cuántas extensiones con SAP BTP y ABAP Cloud han construido, y pida verlas.
¿Qué es RISE with SAP y es adecuado para mi organización?
RISE with SAP es el paquete de suscripción de SAP para SAP Cloud ERP Private: el software, la infraestructura y las operaciones gestionadas por SAP, y un conjunto de herramientas para análisis de procesos, arquitectura y gestión del ciclo de vida. La implementación la sigue entregando su socio.
Encaja con organizaciones grandes que dejan ECC y quieren un único contrato con SAP para plataforma y operaciones. Las empresas medianas que pueden trabajar cerca del estándar deberían considerar GROW with SAP sobre la edición pública.
Escrito por
Noel D'Costa
Por qué los proyectos SAP se salen del presupuesto y cómo evitarlo
La mayoría de los sobrecostos en SAP empiezan con una cifra baja al inicio y un alcance real que solo aparece en la fase Explore. Las causas, las señales de alerta y los controles que lo evitan.
Cronograma de implementación de SAP: duración de fases y 5 errores
Cuánto tarda una implementación de SAP con GROW, RISE o desde ECC, cuánto dura cada fase de SAP Activate y los cinco errores de planificación detrás de la mayoría de los desvíos.
Plantilla de caso de negocio de SAP: obtenga aprobación sin demora
Los casos de negocio de SAP se atascan por cómo están escritos, no por la tecnología. La estructura, los costos que deben figurar y cómo mostrar un ROI que un CFO crea.
Cómo empezar bien su proyecto de implementación de SAP
La mayoría de los problemas de una implementación de SAP ya se ven en el primer mes. Qué definir antes de configurar y los seis patrones de fallo que conviene vigilar.
Siguiente paso
¿Dirige ahora mismo un programa ERP?
Si este artículo toca un programa en el que está inmerso ahora mismo, una conversación de 30 minutos suele avanzar más que otra semana de análisis interno.