Metodología RISE with SAP: qué es hoy (Entrega 1/3)

RISE with SAP ya no describe un único producto, describe una ruta, un conjunto de herramientas de gobernanza y una estructura de acompañamiento que SAP y sus partners usan para llevar a los clientes SAP existentes a la nube. Este es el primero de tres artículos sobre el tema: esta entrega cubre qué es RISE with SAP hoy, cómo ha evolucionado y cómo se conecta con clean core a nivel estratégico. La segunda entrega profundiza en uno de los cinco principios de clean core, la extensibilidad: los cuatro niveles de extensibilidad, qué diferencia una extensión «limpia» de un BAdI o un user exit, y la mecánica práctica para mantenerse estable ante las actualizaciones. La tercera cubre los otros cuatro principios: procesos de negocio, datos, integración y operaciones.

Análisis | ~16 min de lectura | Por J. Torre

En resumen

RISE with SAP se refería originalmente a un paquete comercial específico centrado en SAP Cloud ERP Private Edition. SAP lo ha reposicionado desde entonces como la metodología y el marco comercial para todo el viaje hacia SAP Business Suite en la nube, no solo una decisión de hosting para un producto.
La metodología RISE with SAP se apoya en tres componentes: un marco estandarizado basado en SAP Activate, una cadena de herramientas integrada (SAP Signavio, SAP LeanIX, SAP Cloud ALM, entre otras) y orientación experta de SAP y partners certificados.
Los clientes llegan a SAP Business Suite por una de tres rutas: un despliegue greenfield de SAP S/4HANA Cloud Public Edition, una conversión de sistema (brownfield) a SAP Cloud ERP Private, o un modelo híbrido de dos niveles que combina ambos.
Clean core no es una recomendación secundaria dentro de esta metodología: es la disciplina arquitectónica que todo el marco está diseñado para hacer cumplir, mediante órganos de gobernanza como el Solution Standardization Board y quality gates recurrentes.
Encuestas independientes de DSAG y ASUG muestran un panorama más mixto sobre el terreno del que sugieren los materiales propios de SAP: los costes de licencias, la protección de datos y la integración siguen siendo los obstáculos más citados, y una parte considerable de los miembros de DSAG reporta ver poco valor añadido hasta ahora.

Qué es RISE with SAP realmente hoy

SAP creó RISE with SAP en 2021 como una forma de vender una transformación a S/4HANA Cloud Private Edition como una suscripción única: el software, la infraestructura del hyperscaler, herramientas de migración y un conjunto definido de servicios, todo bajo un mismo contrato. Durante varios años, eso fue esencialmente lo que el término significaba en la práctica: un paquete comercial específico construido en torno a una edición de producto.

Eso ya no describe la situación con precisión. Como indican los propios materiales de la metodología RISE with SAP de SAP, «tradicionalmente, RISE with SAP era un paquete de ventas específico, que incluía SAP Cloud ERP Private», pero la compañía ha evolucionado el modelo desde entonces «para ofrecer un soporte continuo y enfocado» a través de un portfolio más amplio: ERP en nube pública y privada, y soluciones de línea de negocio entregadas bajo el paraguas de SAP Business Suite. El nombre RISE with SAP se refiere cada vez más a la metodología de transformación y al marco comercial que lleva a un cliente existente desde un panorama SAP local legacy hasta SAP Business Suite en la nube, independientemente de la combinación concreta de productos que termine incluyendo ese viaje.

Esta distinción importa a la hora de leer una propuesta de RISE with SAP en 2026. No es una lista de compra fija. Es una metodología de proyecto, un modelo de gobernanza y una cadena de herramientas, envueltos alrededor de la combinación de SAP Cloud ERP Private, SAP S/4HANA Cloud Public Edition y productos de línea de negocio (SAP Ariba, SAP Concur, SAP SuccessFactors) que mejor encaje con el panorama del cliente.

Los tres componentes de la metodología RISE with SAP

SAP describe la metodología RISE with SAP como la combinación de tres elementos.

El primero es un marco estandarizado. Amplía SAP Activate —la metodología de implementación consolidada de SAP— con actividades específicas de clean core y puntos de control de calidad añadidos sobre las fases habituales: Discover, Prepare, Explore, Realize, Deploy y Run. El marco aporta hojas de ruta de proyecto, hitos y un conjunto definido de tareas y aceleradores, en lugar de dejar que cada partner de implementación improvise la gobernanza desde cero.

El segundo es una cadena de herramientas integrada. Tres herramientas hacen la mayor parte del trabajo: SAP Signavio para el análisis de procesos (minería de procesos, documentación y gobernanza en notación BPMN), SAP LeanIX para arquitectura empresarial y gestión del portfolio de aplicaciones, y SAP Cloud ALM, que funciona como la capa de conexión: aloja la lista de tareas del proyecto, hace seguimiento de los quality gates y, más adelante, se convierte en el panel para monitorizar el cumplimiento de clean core durante la operación. SAP ha indicado que SAP Cloud ALM hace seguimiento de más de 150 tareas recomendadas de clean core, mapeadas a lo largo de las fases de SAP Activate, como parte del Clean Core Success Plan que se configura durante el onboarding.

El tercero es la orientación experta: advisors de onboarding, arquitectos empresariales y partners cualificados que trabajan junto al equipo propio del cliente, en lugar de un conjunto de herramientas puramente de autoservicio.

Tres rutas hacia SAP Business Suite

Como los clientes parten de puntos de arranque muy distintos, la metodología define tres rutas de transformación principales en lugar de un único camino.

Una adopción greenfield, o desde cero, significa desplegar SAP S/4HANA Cloud Public Edition partiendo de cero, adoptando los procesos estándar de SAP y las mejores prácticas del sector sin arrastrar personalización heredada. Esta ruta encaja con organizaciones que buscan el despliegue más rápido y la menor deuda técnica heredada, a costa de renunciar a procesos a medida que pueden haber tardado años en construirse.

Una conversión de sistema, a veces llamada migración brownfield, convierte un sistema SAP ECC existente en SAP Cloud ERP Private Edition. Esto preserva datos históricos, integraciones existentes y lógica de negocio en la que la organización ya ha invertido, aunque sigue requiriendo una evaluación de clean core sobre qué se traslada tal cual y qué se reconstruye usando APIs liberadas.

Una estrategia híbrida, o de dos niveles (two-tier), combina ambas: una multinacional puede ejecutar SAP Cloud ERP Private en su sede central para conservar funcionalidad compleja y específica del sector, mientras filiales o divisiones recién adquiridas ejecutan SAP S/4HANA Cloud Public Edition sobre procesos estándar. SAP Business Technology Platform actúa entonces como la capa de integración que conecta ambos niveles.

Ninguna de estas rutas es intrínsecamente «más RISE with SAP» que otra: la metodología, la cadena de herramientas y el modelo de gobernanza se aplican a las tres por igual.

Discover y Prepare: qué ocurre realmente antes de que arranque un proyecto

Dos fases estructuradas se sitúan al inicio de un viaje RISE with SAP, y son importantes porque es ahí donde se adquieren —o no— los compromisos de clean core.

Durante la fase Discover, los equipos de ventas y preventa usan el Digital Discovery Assessment (DDA), un cuestionario estructurado y formato de taller que recoge los requisitos de arquitectura de IT del cliente, el alcance planificado y las necesidades de licencias. Como complemento, SAP Signavio Process Insights aporta visibilidad inmediata sobre cómo funcionan realmente los procesos de negocio del cliente, y SAP LeanIX inventaría el panorama de aplicaciones existente. SAP Readiness Check añade una evaluación técnica de la preparación del sistema actual para la conversión. Juntos, estos elementos producen los artefactos —incluyendo una línea base inicial de clean core y un mapa de capacidades de negocio— que se transfieren del equipo de ventas al equipo de implementación cuando el proyecto avanza hacia Prepare.

El Transformation Preparation Service (TPS), dirigido específicamente a clientes de SAP Cloud ERP Private, retoma el trabajo donde lo deja el DDA. Es un servicio breve e intensivo —normalmente una sesión de alineación seguida de un taller de tres días con especialistas de SAP— estructurado en torno a tres bloques: revisar la arquitectura de IT objetivo y establecer una línea base de clean core el primer día, identificar casos de uso de Business AI y Joule el segundo día, y formalizar el modelo de gobernanza, incluyendo la creación de un Solution Standardization Board, el tercer día. El taller se cierra con playbooks de gobernanza, un plan de activación de la cadena de herramientas (conectando Signavio, LeanIX y Cloud ALM) y una hoja de ruta de transición detallada.

El propósito del TPS es explícito en la propia descripción de SAP: cerrar la brecha entre lo que prometió preventa y lo que realmente entrega el proyecto de implementación, traduciendo la intención estratégica en una arquitectura y un modelo de gobernanza concretos antes de que arranque el trabajo técnico.

Gobernanza: el Solution Standardization Board

El Solution Standardization Board (SSB), formalizado durante el TPS, funciona como un comité de revisión de arquitectura durante toda la vida del proyecto y, habitualmente, más allá de él. Su función es evaluar cualquier desviación propuesta respecto al estándar de SAP antes de que se construya.

En la práctica, el SSB hace cuatro cosas. Realiza gestión de gaps: antes de aprobar cualquier desarrollo a medida, comprueba si el requisito ya puede cubrirse con funcionalidad o configuración estándar de SAP. Exige justificación estratégica: una desviación solo se aprueba si responde a un requisito regulatorio genuino o a una capacidad que diferencia de forma significativa al negocio, no a una preferencia general por cómo funcionaba antes un proceso. Revisa las Key Design Decisions para mantener la arquitectura objetivo alineada con los principios de clean core a medida que evoluciona el proyecto. Y gobierna cómo se construye cualquier extensión aprobada, comprobando específicamente que se sitúe fuera del núcleo del ERP —normalmente side-by-side sobre SAP Business Technology Platform— y que consuma únicamente APIs liberadas en lugar de modificar el código fuente directamente.

Este es el mecanismo de gobernanza que le da fuerza real a clean core. Sin un órgano con autoridad para decir que no a una solicitud de personalización —y para tomar esa decisión antes de que se escriba el código, no durante una actualización fallida dos años después—, clean core sigue siendo una aspiración y no una restricción que se mantiene.

Por qué clean core es el eje central, no un añadido

Sería fácil leer clean core como un punto más en una lista de comprobación, junto a la migración, las licencias y la formación. Los propios materiales de SAP lo tratan de forma distinta: como la base arquitectónica que el resto de la metodología está diseñada para proteger.

Clean core se apoya en cinco principios rectores, cada uno con su propio objetivo. Los procesos de negocio deben mantenerse cerca del estándar de SAP, adoptando una mentalidad «fit-to-standard» que parte de la pregunta de cómo puede adaptarse la organización a las mejores prácticas probadas del sector, en lugar de cómo forzar al sistema para que replique procesos históricos, reservando la desviación a medida para los casos con valor de negocio real y medible. La extensibilidad debe desacoplar el código a medida del sistema estándar, construyéndose side-by-side sobre SAP Business Technology Platform o on-stack mediante ABAP Cloud, usando únicamente APIs liberadas. Los datos deben gobernarse conforme a estándares actuales de estrategia de datos, gobernanza, calidad y gestión de volumen, ya que la automatización y las funciones de IA fiables no pueden operar sobre datos inconsistentes. La integración debe apoyarse en APIs liberadas y patrones basados en eventos, en lugar de conexiones a medida punto a punto y frágiles construidas dentro del ERP. Y las operaciones deben pasar de una resolución de problemas reactiva y manual hacia una gestión del sistema estandarizada y automatizada.

La metodología trata estos cinco principios como interdependientes, no como una lista de comprobación que se completa de forma independiente: un proceso de negocio que se desvía del estándar tiende a requerir extensiones a medida para sostenerlo, lo cual a su vez crea dependencias de datos e integración que complican las operaciones. La gobernanza de clean core existe para detener esa reacción en cadena antes de que empiece, no para limpiarla después.

Qué debería aportar clean core, según cada perfil

SAP plantea el beneficio de forma distinta según quién pregunte, y ese enfoque resulta útil porque explica por qué tres funciones distintas dentro de una organización cliente terminan aprobando la misma transformación.

Para IT, un clean core simplifica las actualizaciones del sistema porque hay menos código a medida que volver a probar en cada versión de SAP, reduce la carga de mantenimiento de funcionalidad no utilizada o duplicada, y disminuye el riesgo operativo y de ciberseguridad al minimizar el número de modificaciones no documentadas que un atacante —o un auditor— podría encontrar. Para los usuarios finales, significa trabajar sobre una única versión coherente de los datos de negocio en lugar de reconciliar cifras entre sistemas desconectados, y elimina los silos departamentales que se acumulan cuando cada equipo mantiene su propia solución alternativa. Para la organización en su conjunto, se traduce en mayor agilidad —la capacidad de adoptar una nueva funcionalidad de SAP, incluidas las funciones de IA generativa construidas sobre Joule, sin necesitar antes un proyecto de compatibilidad de varios meses— y, con el tiempo, un menor coste total de propiedad, al destinar menos recursos a mantener con vida personalizaciones heredadas en cada ciclo de actualización.

Ninguno de estos beneficios es automático. Dependen de que la gobernanza se aplique realmente, que es precisamente la brecha que cubre la siguiente sección.

Dónde encaja la IA agéntica en la cadena de herramientas

La evolución más reciente de la metodología RISE with SAP, introducida junto con el mensaje de la Autonomous Enterprise de SAP en 2026, añade lo que SAP llama una cadena de herramientas «agent-led» (dirigida por agentes) al marco estandarizado y a la orientación experta descritos anteriormente. En la práctica, esto significa que asistentes de migración y modernización —construidos sobre la misma SAP Business AI Platform que sustenta Joule— se integran en la propia transformación, en lugar de ser un flujo de trabajo aparte añadido más tarde.

El objetivo es integrar las actividades de migración y modernización en un enfoque único y más automatizado: asistentes que ayudan a acelerar el trabajo técnico de migración, de modo que la reducción de complejidad y coste se traduzca en un avance más rápido y medible hacia un clean core, en lugar de un proyecto más lento y puramente manual. Esto importa para entender cómo encaja la metodología en el resto de la hoja de ruta actual de SAP, porque la compañía ha sido explícita en que un núcleo limpio y gobernado es un requisito previo para una IA agéntica fiable: un agente solo puede actuar con seguridad sobre datos y procesos de negocio en los que puede confiar, que es exactamente lo que los cinco principios de clean core garantizan. En ese sentido, la cadena de herramientas agent-led de RISE with SAP es menos una función nueva que una demostración de por qué la metodología insistió en clean core desde el principio: el enfoque de transformación y el destino se refuerzan mutuamente.

Aquí es también donde aumenta la exigencia práctica de la metodología. Un asistente de migración que recomienda cómo remediar una trozo de código a medida solo es fiable si la clasificación subyacente de ese código —API liberada, API clásica, objeto interno o patrón explícitamente desaconsejado— es precisa y está actualizada. Esa clasificación es precisamente lo que el concepto de nivel de clean core proporciona, y es el tema de la segunda entrega de esta serie.

Qué dice realmente el ecosistema SAP

Los materiales propios de SAP describen una trayectoria bastante lineal: de paquete comercial a metodología, de ahí a disciplina de clean core y, finalmente, a valor de negocio medible. Las fuentes independientes muestran un panorama más desigual, y una lectura rigurosa de RISE with SAP debería incluir ambas perspectivas.

Las encuestas del grupo de usuarios de habla alemana DSAG y del grupo norteamericano ASUG muestran una brecha real de percepción de valor: solo alrededor del 12% de los miembros de DSAG y el 24% de los de ASUG valora actualmente la oferta de transformación de SAP como de alto o muy alto valor, mientras que aproximadamente el 39% de los miembros de DSAG y el 11% de los de ASUG reportan ver poco o ningún valor añadido por el momento. En ambos grupos, el obstáculo más citado no es técnico: son los modelos de licencias y costes (citado por el 72% de los miembros de DSAG y el 41% de los de ASUG), seguido de las preocupaciones sobre protección de datos y seguridad de la información, y después la complejidad de integración. Los panoramas híbridos, y no la adopción plena en nube pública, siguen siendo la norma para la mayoría de los encuestados.

En el terreno específico de la extensibilidad, la comunidad de SAP ha sido más abiertamente crítica que los propios white papers de SAP. Una publicación ampliamente comentada argumenta que el planteamiento general de «mantener el núcleo limpio» subestima un problema práctico real: los desarrolladores acostumbrados durante dos décadas a recurrir a un user exit, un BAdI clásico o una mejora implícita cada vez que necesitan incrustar lógica a medida han creado una red de dependencias sobre código entregado por SAP que un planteamiento centrado solo en las actualizaciones no captura del todo, porque alejarse de esos patrones exige reconstruir conocimiento institucional, no solo sustituir una API por otra. Esa tensión entre lo que recomienda un marco de gobernanza y lo que un equipo ABAP con experiencia ha tardado años en construir es un tema recurrente en los comentarios del ecosistema, y es una de las razones por las que SAP introdujo el modelo de clean core de cuatro niveles, más gradual (que se cubre en la segunda entrega de este artículo), en lugar de un binario estricto entre «limpio» y «no limpio».

Leído en conjunto, nada de esto contradice lo que SAP describe como para lo que la metodología y clean core están diseñados. Sí sugiere que la brecha entre el framework y su aplicación en un proyecto de transformación real, de varios años, es donde se concentra la mayor parte de la dificultad real: un tema que reaparece, en forma mucho más técnica, en cuanto se entra en el funcionamiento práctico de la extensibilidad de clean core.

Qué sigue

Esta entrega cubrió RISE with SAP como metodología: qué cambió desde 2021, los tres componentes que la conforman, las rutas hacia SAP Business Suite y cómo la gobernanza está diseñada para hacer cumplir la disciplina de clean core desde el primer workshop. La segunda entrega de esta serie entra en el funcionamiento interno de uno de los cinco principios de clean core, la extensibilidad: el modelo de cuatro niveles (desde APIs completamente liberadas hasta técnicas claramente desaconsejadas), qué separa realmente una API liberada de un BAdI o un user exit en la práctica, la decisión entre on-stack y side-by-side para una extensión concreta, y los KPI que recomienda SAP para medir si esa parte de una estrategia de clean core funciona de verdad, y no solo está documentada. La tercera entrega cubre los cuatro principios restantes — procesos de negocio, datos, integración y operaciones — y el marco de medición que usa SAP para puntuar los cinco en conjunto.