Plantillas de implementación de SAP: guía fase por fase

SAP Activate incluye una plantilla para casi todos los entregables de un programa de S/4HANA. Las encontrará en el SAP Activate Roadmap Viewer y, en los programas en la nube, dentro de SAP Cloud ALM. Encontrarlas es fácil. Saber cuáles tomarse en serio es lo difícil.

Esta guía es para gerentes de programa, líderes de PMO y patrocinadores que ponen en marcha una implementación. Recoge las plantillas que exijo en cada fase, muestra un formato de trabajo para cada una e indica dónde los equipos recortan camino. Si le queda una semana antes del kickoff, haga primero el documento de alcance y la matriz de interesados. Todo lo demás se apoya en esos dos.

El patrón es coherente en los programas de ECC y S/4HANA en los que he trabajado, en manufactura, retail y servicios financieros. Los equipos que siguen las plantillas detectan los problemas antes. Los que las tratan como papeleo opcional descubren a mitad del proyecto que cada decisión que nunca dejaron por escrito se ha convertido en una disputa sobre el alcance.

Este es el conjunto que espero ver firmado, con la persona responsable de cada una y el punto que debe superar.

Fase	Plantilla	Responsable	Firmada antes de
Prepare	Documento de alcance del proyecto	Gerente del programa (aprueba el patrocinador)	Que empiece Explore
Prepare	Caso de negocio	CFO o responsable del negocio	Que se libere la financiación
Prepare	Matriz de interesados	Gerente del programa	Que se reserven los talleres de Explore
Explore	Hoja de requisitos y fit-gap	Arquitecto de soluciones con los responsables de proceso	Que empiece Realize
Realize	Registro de configuración	Líderes funcionales	Que cada transporte pase a QA
Realize	Registro de desarrollos a medida	Líder de desarrollo	Que empiece la construcción de cualquier objeto
Realize	Estrategia de pruebas	Responsable de pruebas	Que empiecen las pruebas de integración del sistema
Realize	Plan de migración de datos	Líder de migración de datos	La primera carga de prueba
Deploy	Plan de cutover	Responsable del cutover	El último ensayo general
Deploy	Evaluación de preparación para el go-live	Director del programa (firma el patrocinador)	La reunión de go/no-go
Run	Modelo de soporte de hypercare	Líder de entrega de servicios	El go-live
Run	Hoja de monitorización del rendimiento	Líder de Basis	El go-live

Activate tiene seis fases: Discover, Prepare, Explore, Realize, Deploy y Run. Combina el contenido de SAP Best Practices, la configuración guiada y un enfoque de entrega ágil. Para la mayoría de los clientes Discover ocurre antes de firmar el contrato, así que las plantillas de abajo empiezan en Prepare.

1. 01DiscoverNormalmente antes de firmar el contrato
2. 02PrepareDocumento de alcance, caso de negocio, matriz de interesados
3. 03ExploreHoja de requisitos y fit-gap
4. 04RealizeRegistro de configuración, registro de desarrollos, estrategia de pruebas, plan de migración
5. 05DeployPlan de cutover, preparación para el go-live
6. 06RunModelo de hypercare, monitorización del rendimiento

Todas las plantillas firmadas antes de su gate

La secuencia de fases no es opcional. Trabajé con un retailer que intentó saltarse partes de ella y acabó rehaciendo tres meses de trabajo. Cada quality gate existe por una razón.

Al adaptar las plantillas, conserve alrededor del 80 % de la estructura estándar. Cambie solo lo que refleje su contexto: requisitos del sector, controles regulatorios, particularidades regionales. Reescribirlo todo anula el sentido de usarlas.

Qué cambió en las herramientas para 2026

La estructura de Activate es la misma de siempre. Han cambiado las herramientas que la rodean.

1. SAP Cloud ALM aloja las plantillas en los programas en la nube. Es el sucesor de Solution Manager en el catálogo de SAP y se incluye con SAP Enterprise Support y con suscripciones en la nube como RISE with SAP. El alcance, los requisitos, los planes de pruebas y las tareas de cutover pueden vivir ahí, con trazabilidad entre ellos. Solution Manager 7.2 sale del mantenimiento estándar a finales de 2027, con mantenimiento ampliado hasta 2030 para algunas funciones, así que los entornos on-premise existentes tienen unos pocos años, no una década.
2. Joule ya está dentro de las herramientas de la metodología. SAP puso Joule a disposición en el Activate Roadmap Viewer en 2025 y en SAP Cloud ALM, de modo que un equipo puede pedir orientación sobre tareas o redactar contenido a partir de la hoja de ruta. Acelera el primer borrador. No sustituye a la persona que firma el fit-gap.
3. Clean core es ahora una regla de diseño, con niveles. En agosto de 2025 SAP sustituyó su modelo de extensibilidad de tres capas por cuatro niveles de clean core, de A a D. El nivel A usa solo API liberadas, ya sea en SAP BTP o dentro del sistema con ABAP Cloud. El nivel D no es limpio en absoluto. La plantilla de fit-gap necesita una columna que indique dónde terminará cada gap.
4. La edición pública estrecha el fit-gap. SAP comercializa ahora S/4HANA Cloud Public Edition como SAP Cloud ERP, y lo vende a empresas medianas como SAP GROW. Se aplican las mismas seis fases con artefactos más ligeros, y solo se permiten extensiones con API liberadas, así que la columna de «gap» tiene menos respuestas posibles.

Los proyectos que se saltan este trabajo previo lo pagan en Explore y Realize.

Plantilla de alcance del proyecto

Define qué incluye el proyecto y qué no. Cuando alguien intente añadir alcance a los tres meses (y lo hará), este documento es el punto de referencia. El acta de constitución del proyecto SAP está por encima y recoge el detalle de gobierno.

Sección	Detalles
Título, patrocinador, PM	Implementación de SAP S/4HANA Finance; CFO; gerente de proyecto senior designado
Antecedentes	Situación actual y motivo del cambio
Objetivos	Reducir el ciclo de cierre de 14 a 5 días; eliminar las conciliaciones manuales
Dentro del alcance	FI/CO, integración MM/SD, migración de datos, UAT, go-live
Fuera del alcance	Módulos de RR. HH., migración de informes heredados, integraciones de terceros más allá del ERP
Supuestos	Patrocinador ejecutivo disponible para el comité directivo mensual; datos de prueba acordados en la semana 6
Restricciones	Fecha de go-live fija; solo recursos internos para la configuración
Entregables	Sistema configurado, planes de pruebas, plan de cutover, materiales de formación
Cronograma	Prepare: semanas 1-4; Explore: semanas 5-10; Realize: semanas 11-26
Aprobación	Se requiere la firma del patrocinador del proyecto y de la PMO antes de que empiece Explore

Plantilla de caso de negocio

Recorre el análisis costo-beneficio en un formato que el equipo de finanzas puede leer. He visto a clientes obtener la aprobación del programa a la primera con esta estructura, porque las cifras son claras y los supuestos están escritos.

Una regla que mantengo: el integrador de sistemas que va a ejecutar el trabajo no debe escribir este documento. Su incentivo es empezar. El suyo es terminar. Mi plantilla de caso de negocio de SAP profundiza en el modelo de beneficios.

Sección	Detalles
Responsable y resumen	CFO o director del programa; por qué ahora, qué cambia, qué sigue igual
Planteamiento del problema	Problemas operativos concretos (duración del cierre, soluciones manuales provisionales, antigüedad del sistema)
Enfoque propuesto	Greenfield / brownfield / selectivo, con un resumen del alcance
Beneficios	Cuantificados: días menos en el cierre, ahorro en FTE, reducción de la tasa de errores, reducción del riesgo de auditoría
Costo y financiación	Implementación, licencia o suscripción, tiempo de recursos internos, contingencia; origen del presupuesto
Riesgos	Los tres principales, con probabilidad e impacto
Recomendación	Continuar / continuar con condiciones / aplazar, con su justificación

Matriz de identificación de interesados

Reúne a todos los afectados por la implementación y su nivel de influencia. Le dice de un vistazo quién necesita actualizaciones semanales y quién solo necesita un aviso antes del go-live.

Interesado	Rol	Interés	Influencia	Participación
CFO del grupo	Patrocinador ejecutivo	ROI del programa, mejora del cierre financiero	Alta	Comité directivo mensual, informe escrito semanal
Director de TI	Responsable técnico	Estabilidad del sistema, integración, seguridad	Alta	Comité del programa semanal, a diario durante Realize
Director de finanzas	Responsable clave de proceso	Diseño de FI/CO, proceso de cierre	Alta	Talleres en Explore, aprobación de UAT
Gerentes de planta	Usuarios afectados	Cambios en los procesos de MM/PP	Media	Comunicación mensual sobre el cambio, participación en UAT
Usuarios finales (AP/AR)	Operadores	Cambios a nivel de transacción	Baja	Formación, soporte de hypercare
Auditoría interna	Gobierno	Trazabilidad, controles, cumplimiento	Media	Revisión de artefactos en los quality gates

Use la misma matriz para planificar los talleres de Prepare que recogen los requisitos de alto nivel por departamento. Numere esos requisitos con el formato que usará en Explore (REQ-001 y así sucesivamente), para que nada se renumere después y se conserve la trazabilidad hasta la petición original.

Explore es donde la implementación toma forma. Estas plantillas dejan al descubierto la distancia entre lo que SAP hace de serie y lo que el negocio necesita.

Plantilla de mapeo de requisitos y fit-gap

El mapeo de requisitos recoge las necesidades del negocio por departamento y traza cada una hasta un componente del sistema y un caso de prueba. He visto empresas que se lo saltaron y acabaron con sistemas que nadie usa, porque la construcción se basó en lo que los consultores suponían y no en lo que el negocio había dicho.

El análisis fit-gap muestra después dónde SAP estándar cubre cada necesidad y dónde no. Es un verdadero descubrimiento para la mayoría de mis clientes. Me gusta ver el momento en que un equipo se da cuenta de que puede usar funcionalidad estándar en lugar de desarrollos a medida caros.

Mantengo ambos en una sola hoja, con una columna para la vía de resolución. En S/4HANA cada gap necesita una respuesta explícita: configuración estándar, extensión de key user, extensión de desarrollador dentro del sistema o extensión side-by-side en SAP BTP. Las modificaciones clásicas al código de SAP son la respuesta más cara y deberían requerir un aprobador con nombre y apellido.

ID de req.	Requisito	Componente SAP	Fit / Gap	Vía de resolución	Ref. de prueba
REQ-001	Asientos automáticos de cierre mensual	FI-GL, cierre de periodo	Fit	Configurar plantillas de documentos recurrentes	TC-001
REQ-002	Aprobación de pedidos de compra mediante Fiori	Compras MM, app de aprobación de Fiori	Gap (no existe en ECC)	App estándar de S/4HANA y configuración del workflow	TC-003
REQ-003	Automatización de la facturación intercompany	Facturación SD, integración con FI	Gap	Configuración de la facturación intercompany	TC-010
REQ-004	Monitorización de jobs por lotes	App Application Jobs	Fit	App estándar	TC-015
REQ-005	Portal de autoservicio para proveedores	SAP Ariba o portal de proveedores	Gap	Integración con Ariba	TC-020
REQ-006	Archivado de datos conforme al RGPD	ILM, archivado de datos	Gap	Configuración de políticas de ILM	TC-025
REQ-007	Informes de centros de costos en tiempo real	CO, analítica embebida o SAC	Gap	Analítica embebida o conexión live con SAC	TC-030
REQ-008	Admitir 500 usuarios concurrentes	Dimensionamiento de HANA	Gap (300 probados)	Revisión del dimensionamiento y ampliación de la infraestructura	TC-035

Esta es la fase de construcción. Estas plantillas son el rastro de auditoría de cada decisión de configuración, cada desarrollo y cada resultado de prueba.

Plantilla de seguimiento de la configuración

Registra cada cambio en el sistema: quién lo hizo, por qué y en qué transporte fue. Cuando algo falla más adelante, usted rastrea el problema en minutos y no en días.

1. ID de configuración y módulo: [p. ej., MM-CONF-001, MM]
2. Ruta del IMG y objeto de configuración: [p. ej., tabla T161, tipos de documento de pedido]
3. Finalidad y proceso de negocio afectado
4. Configurado por y fecha
5. Número de orden de transporte: [p. ej., DEVK900123]
6. Valores clave: antes y después
7. Casos de prueba vinculados
8. Estado de validación y aprobación

Registro de desarrollos a medida

Cada objeto a medida recibe una fila antes de que nadie escriba código. Uno de mis clientes redujo su código a medida en un 30 % porque el registro mostró dónde SAP estándar funcionaría perfectamente.

ID de desarrollo	Objeto	Descripción	Desarrollador	Esfuerzo (h)	Estado	Tipo de extensión
CD-001	Tile de Fiori: resumen de centros de costos	Tile de informes de CO en tiempo real para finanzas	Desarrollador de Fiori	12	Completado	Extensión de desarrollador
CD-002	Informe de facturación intercompany	Informe para la conciliación intercompany	Desarrollador de ABAP	20	En curso	Extensión de desarrollador
CD-004	App de estado de pagos a proveedores	App de Fiori para consultas de pagos de cuentas por pagar	Desarrollador de BTP	10	Pendiente de QA	Side-by-side en BTP
CD-005	Notificación de entrada de mercancías	Envío de correo al contabilizar una entrada de mercancías	Desarrollador de integraciones	24	Planificado	Basado en eventos, en BTP

Plantilla de estrategia de pruebas

Reúne en un solo lugar todos los planes de pruebas: quién prueba qué, cuándo, en qué entorno y con qué estándar.

Sección	Detalles
Alcance	Pruebas funcionales, de integración, de regresión, de rendimiento y UAT en los módulos incluidos en el alcance (las pruebas de penetración corresponden a seguridad de la información)
Entornos	DEV, QA, UAT (preproducción), staging para la validación final
Herramientas	Gestión de pruebas en SAP Cloud ALM o Jira/Xray; automatización con Tricentis Tosca o similar; rendimiento con JMeter o LoadRunner
Ciclo de vida de los defectos	Nuevo, En curso, Resuelto, Verificado, Cerrado; severidad y prioridad definidas en el triaje
Criterios de salida	Todos los defectos críticos cerrados; aprobación de UAT recibida; tasa de éxito de regresión de al menos 95 %; referencias de rendimiento alcanzadas

Plantilla de planificación de la migración de datos

La migración de datos es el flujo de trabajo con más probabilidades de hacerle daño. Esta plantilla lo divide en pasos que sacan a la luz los problemas de calidad de datos antes del cutover y no durante él. El artículo sobre los patrones de fallo en la migración de datos explica qué sale mal cuando se omite.

Sección	Detalles
Alcance	Datos maestros de clientes, datos maestros de proveedores, partidas abiertas, datos maestros de materiales, saldos de existencias, jerarquías de centros de costos
Sistemas de origen	ECC 6.0 EHP 7 (principal); sistema de RR. HH. heredado (asignaciones de empleados a centros de costos)
Sistema de destino	S/4HANA (versión actual)
Mapeo y reglas	Clientes y proveedores a Business Partner; centros de costos a la nueva jerarquía; eliminar datos bancarios no válidos; fusionar duplicados
Herramientas de migración	SAP S/4HANA Migration Cockpit (principal); Migration Object Modeler para objetos personalizados; scripts de preprocesamiento
Estrategia de carga	Carga de prueba en QA; migración delta y conciliación; cutover a producción
Enfoque de validación	Recuento de registros de origen a destino; muestreo aleatorio del 10 %; informes de conciliación de saldos
Plan de rollback	Copia de seguridad previa al cutover; sistema heredado en espera durante 48 horas

La fase Deploy es cuando se pone en marcha. Estas plantillas convierten un fin de semana caótico en un evento gestionado.

Plantilla de planificación del cutover

Define la ventana de bloqueo hora por hora. Cada tarea, cada responsable, cada hora de inicio. Su equipo nunca debería estar parado a las 2 de la madrugada preguntándose qué hacer a continuación.

Acuerde cuatro cosas antes de escribir la lista de tareas: la ventana (por ejemplo, de las 22:00 del viernes a las 06:00 del sábado), el disparador del rollback, la rapidez con que se puede reactivar el sistema heredado y las pruebas de humo que demuestran que el sistema nuevo funciona. Después, la secuencia de tareas:

Paso	Descripción	Responsable	Hora de inicio	Estado
1	Congelar el sistema ECC (sin contabilizaciones)	Basis	22:00	Pendiente
2	Extracción final de datos y conciliación	Líder de migración de datos	22:30	Pendiente
3	Ejecutar la carga de migración en producción	DBA	23:00	Pendiente
4	Importar a producción los transportes restantes	Basis	00:30	Pendiente
5	Cambio de DNS y del balanceador de carga a S/4HANA	Redes	01:30	Pendiente
6	Prueba de humo: contabilización en FI, entrada de mercancías, pedido de venta	Líder de QA	02:00	Pendiente
7	Confirmación del negocio y decisión de go/no-go	Director del programa	03:00	Pendiente
8	Abrir el sistema a los usuarios del negocio	Basis	06:00	Pendiente

Evaluación de preparación para el go-live

Decide si realmente está listo para el cambio. He tenido clientes que retrasaron el go-live a partir de esta evaluación, y después me lo agradecieron.

Área	Comprobaciones (cada una se responde con sí o no, con evidencia)
Funcional	Procesos clave probados; escenarios entre módulos completos; defectos P1/P2 abiertos listados; usuarios clave confirman que están listos
Datos	Cargas de datos maestros completas; datos de transacciones validados; informes de conciliación aprobados; congelación del sistema heredado confirmada
Técnico	Plan de cutover aprobado; transportes en producción; jobs por lotes programados; monitorización configurada
Personas	% de cobertura de formación; roles de acceso validados; equipo de hypercare dotado; plan de soporte comunicado
Decisión	Riesgos críticos y mitigaciones listados; Go / No-go / Condicional; aprobado con nombre, rol y fecha

Después del go-live el trabajo cambia de forma. Estas plantillas llevan el sistema y al equipo a través del hypercare hasta el régimen estable.

Plantilla de soporte posimplementación

Organiza cómo se gestionan las incidencias tras el lanzamiento. Sin ella, cada problema se convierte en un P1.

Sección	Detalles
Ventana de hypercare	Semanas 1-4 tras el go-live: cobertura 24/7
Canales de soporte	Cola de incidencias de ServiceNow (principal); canal de chat dedicado; puente telefónico para incidencias P1
Niveles de soporte	1: mesa de servicio (contraseñas, navegación, incidencias conocidas); 2: consultores funcionales (consultas de procesos, configuración menor); 3: Basis y desarrollo (errores del sistema, rendimiento, interfaces)
SLA (respuesta / resolución)	Crítica 15 min / 2 h; Alta 30 min / 4 h; Media 4 h / 1 día; Baja 1 día / 3 días
Monitorización	SAP Cloud ALM o Solution Manager; revisión diaria del registro de errores
Criterios de salida	Sin incidencias P1/P2 abiertas; todas las incidencias documentadas; firma de la entrega final

Plantilla de monitorización del rendimiento

Permite vigilar la salud del sistema día a día y detectar las ralentizaciones antes de que los usuarios se quejen. Hace poco ayudé a una empresa a detectar así un problema de base de datos que habría tumbado su sistema durante el cierre mensual.

Métrica	Objetivo	Herramienta	Umbral de alerta	Responsable
Tiempo de respuesta de diálogo (percentil 95)	Menos de 1 segundo	ST03 / SAP Cloud ALM	2 segundos	Equipo de Basis
Finalización de jobs en segundo plano	100 % según lo programado	SM37 / Application Jobs	Cualquier job fallido	Líder de operaciones
Tiempo de consulta a la base de datos	Menos de 200 ms	SAP HANA cockpit	500 ms	DBA
Disponibilidad del sistema	Más de 99,5 %	SAP Cloud ALM	Menos de 99 %	Infraestructura
Tasa de errores de las interfaces	Menos de 1 %	Monitorización de SAP Integration Suite	2 %	Líder de middleware
Tasa de éxito de inicios de sesión	Más de 98 %	Registro de auditoría de seguridad	Menos de 95 %	Líder de seguridad
Duración del job de cierre mensual	Dentro de la ventana acordada	Planificador de jobs	Más de 30 % por encima de la línea base	Operaciones de finanzas

Los quality gates impiden que un problema de una fase se convierta en un retrabajo caro en la siguiente. Mi guía sobre los quality gates de SAP explica cómo configurarlos. Aquí va por qué importan.

La aprobación ejecutiva antes del go-live no debe ser un simple trámite. En un proyecto en el que trabajé, el CEO detectó durante la revisión del go-live un problema grave que habría perturbado el trabajo del equipo de finanzas.

Fije criterios de aprobado o suspendido en cada gate. «El 95 % de las pruebas de regresión debe pasar.» «Todos los escenarios de integración de FI están en verde.» Criterios como estos le dan una base defendible para mantener la línea cuando el negocio quiere lanzar en una fecha pase lo que pase con la calidad.

En uno de mis proyectos, el quality gate nos detuvo cuando solo el 75 % de las pruebas de integración había pasado. Corregimos los problemas primero en lugar de precipitarnos. Eso le ahorró al cliente unos 100.000 € en correcciones de emergencia tras el lanzamiento.

Un gate que el patrocinador puede anular con una llamada de teléfono no es un gate. Deje por escrito quién puede dispensarlo antes de que haga falta.

¿Qué es la metodología SAP Activate?

SAP Activate es la metodología de implementación de SAP para S/4HANA y sus demás productos en la nube. Se desarrolla en seis fases (Discover, Prepare, Explore, Realize, Deploy, Run) y combina el contenido de SAP Best Practices, la configuración guiada y la entrega ágil.

Las listas de tareas y las plantillas de entregables de cada escenario de despliegue se publican en el SAP Activate Roadmap Viewer.

¿Qué fase de SAP Activate tiene las plantillas más importantes?

Prepare. El documento de alcance, el caso de negocio y la matriz de interesados sientan la base de todas las decisiones posteriores, y son los que los equipos se saltan para llegar antes a la configuración. Ese atajo es la causa más común de disputas sobre el alcance en Realize.

Explore viene en segundo lugar. Los huecos en los documentos de fit-gap y de mapeo de requisitos afloran como defectos de UAT meses después, cuando corregirlos cuesta mucho más de lo que habría costado en la semana 3 de Explore.

¿Se pueden personalizar las plantillas de SAP Activate?

Sí. Conserve alrededor del 80 % de la estructura estándar y cambie solo lo que sea específico de su contexto: validación farmacéutica, normas de contratación del sector público, controles SOX. Añádalos al inicio de Prepare, no en Deploy.

No personalice la estructura de los quality gates, la secuencia de fases ni los artefactos obligatorios (documento de alcance, caso de negocio, evaluación de preparación para el go-live).

¿Funcionan las plantillas de SAP Activate tanto para greenfield como para brownfield?

Sí. La diferencia principal está en Explore. Una conversión brownfield arrastra la configuración existente, así que el fit-gap se centra en lo que hay que cambiar, qué código a medida puede reemplazar ahora S/4HANA estándar y qué depuración de datos hace falta antes de la conversión. Un programa greenfield parte de SAP Best Practices y confirma qué procesos estándar encajan.

El plan de cutover también difiere. Una conversión de sistema brownfield sigue una secuencia distinta a la de un go-live greenfield con migración completa de datos.

¿Qué nivel de detalle debe tener un plan de cutover?

Hora por hora como mínimo, y más ajustado todavía para la ventana de bloqueo. Cada tarea necesita una hora de inicio, un responsable y una dependencia.

Acuerde los criterios de rollback antes de que empiece el cutover: qué condiciones provocan la vuelta al sistema heredado, quién toma esa decisión y a qué hora como máximo. Las decisiones de rollback tomadas a las 4 de la madrugada sin criterios pactados de antemano son donde empiezan los desastres posteriores al go-live.