Clean Core determina si tu entorno S/4HANA puede de verdad ejecutar la IA agéntica que SAP está lanzando, o si cada piloto de IA termina volviendo, en silencio, a la revisión manual. Qué significa en la práctica, qué cuesta ignorarlo, y cómo encajarlo dentro de una migración en marcha.
En resumen
- Clean core ya no es opcional: las propias herramientas de IA de SAP lo necesitan para funcionar bien, y en torno al 50% de los clientes de SAP ya usa BTP activamente por esa razón, unos 10 puntos más que hace un año, con otro 26% empezando ahora.
- La regla en una frase: nada se modifica dentro del core que entrega SAP. Las extensiones, integraciones y lógica personalizada viven fuera, en BTP, conectadas mediante APIs publicadas.
- Los agentes de IA estándar de SAP, incluido el agente de gestión de caja del artículo de la semana pasada, solo funcionan de fábrica sobre procesos que cumplen con clean core.
- Sin gobierno, la extensibilidad side-by-side en BTP no elimina la deuda técnica, solo la traslada de sitio. El nuevo riesgo se llama sprawl, no personalización.
- Más abajo tienes un mapa de tres niveles de extensibilidad y una checklist de preparación para encajar esto dentro de tu migración a S/4HANA, no después.
La promesa de la semana pasada
El artículo de la semana pasada sobre IA en Finanzas SAP terminaba con una afirmación concreta: en un entorno que no es clean core, no se puede confiar en que un agente de IA actúe de forma autónoma, por muy bueno que sea el modelo. Este artículo desarrolla esa idea en detalle. Si la IA es la capa de la que todo el mundo quiere hablar en 2026, clean core es la capa que decide si esa conversación tiene algo real debajo.
La versión corta, para quien llegue sin contexto: Clean Core es el principio de SAP de mantener el core de S/4HANA lo más cercano posible al estándar, y construir todo lo específico de tu negocio (lógica personalizada, integraciones, extensiones) fuera de él, en SAP Business Technology Platform (BTP), conectado de vuelta mediante APIs publicadas en lugar de modificar directamente el sistema. Suena a norma de higiene técnica. En realidad es una decisión de arquitectura con consecuencias directas sobre la adopción de IA, el coste de las actualizaciones y la velocidad a la que puedes integrar una adquisición.
Por qué 2026 es distinto
Durante los primeros años de S/4HANA, clean core era una recomendación aspiracional, algo que un arquitecto mencionaba en una diapositiva y que rara vez se exigía de verdad. En 2026, tres fuerzas lo han convertido en un requisito crítico de negocio, no en una buena práctica opcional.
- La IA necesita un core estandarizado sobre el que razonar: los agentes Joule y las capacidades de IA embebida de SAP, los mismos del artículo de la semana pasada, necesitan un modelo de datos y un flujo de proceso predecibles y estandarizados para funcionar bien. La personalización pesada rompe el contexto que un agente necesita para interpretar lo que realmente ocurre en tu sistema. Un agente entrenado sobre la lógica estándar de SAP no puede razonar de forma fiable sobre una década de modificaciones en programas Z sin documentar.
- El ritmo de versiones en la nube castiga un core sucio: SAP S/4HANA Cloud lanza actualizaciones trimestrales. En un entorno clean core, esas actualizaciones se absorben con mínima fricción. En uno muy modificado, cada versión trimestral dispara un ciclo de repruebas caro, porque nadie tiene la certeza de qué objeto personalizado interactúa con qué cambio estándar.
- El coste total de propiedad se acumula: el código personalizado dentro del core no cuesta una vez, cuesta cada año siguiente. Cada consultor nuevo tiene que entenderlo, cada actualización tiene que tenerlo en cuenta, cada integración tiene que rodearlo. La deuda no se queda quieta: crece.
El mercado ya ha descontado esto. Varias fuentes del sector, siguiendo las cifras de adopción de SAP, sitúan el uso de BTP en torno al 50% de los clientes de SAP usándolo de forma activa en 2026, unos 10 puntos porcentuales más que el año anterior, con otro 26% empezando su recorrido con BTP. Dicho de otra forma: tres de cada cuatro clientes de SAP ya están en el camino de la extensibilidad en BTP o moviéndose hacia él. La extensibilidad side-by-side en BTP se ha convertido, en la práctica, en la respuesta por defecto a «dónde va esta lógica personalizada», no en una alternativa a valorar frente a la forma de trabajar de siempre.
Qué exige realmente clean core
Quitando el marketing, clean core se reduce a cuatro reglas concretas, todas exigibles y todas comprobables hoy mismo sobre un sistema real.
- No modificar los objetos que entrega SAP: la regla fundamental. No se tocan tablas, programas ni módulos de función estándar de SAP con las técnicas de mejora clásicas que generan dependencias duras en cada actualización. En su lugar, se usa el marco de extensibilidad oficial de SAP: BAdIs, APIs publicadas y la extensibilidad de key user dentro de Fiori.
- Las extensiones viven en BTP, no dentro del core: la lógica personalizada que de verdad no se puede resolver con extensibilidad estándar se construye en BTP, usando el modelo CAP (Cloud Application Programming), SAP Build o SAP Integration Suite. Estas extensiones están desacopladas del core: sobreviven a las actualizaciones de forma independiente, y se pueden desarrollar, probar y desplegar sin tocar el S/4HANA de producción.
- Las integraciones pasan por APIs, nunca por acceso directo a base de datos: cualquier integración con terceros (CRM, WMS, MES, e-commerce) usa una API publicada de SAP: un servicio OData o un evento a través de SAP Integration Suite. Los accesos directos a base de datos o los atajos vía RFC que se saltan la capa de API crean un acoplamiento oculto que se rompe en silencio en cuanto cambia el esquema.
- El gobierno del dato forma parte de clean core, no va aparte: proveedores duplicados, clasificaciones de material inconsistentes, jerarquías de centros de coste heredadas: son el equivalente en datos de un core sucio. Limitan la automatización de procesos tanto como el mal código personalizado, y degradan la calidad de cualquier modelo de IA construido encima. Es exactamente el problema de datos que el artículo de la semana pasada señalaba como el principal obstáculo para el impacto de la IA. No es casualidad que ambos artículos lleguen a la misma raíz.
El mapa de extensibilidad: dónde va cada cosa
Aceptadas las cuatro reglas, la pregunta práctica es: para cada pieza de lógica personalizada, ¿a qué capa pertenece? SAP, y el ecosistema de partners que lo implementa, suele organizar la respuesta en tres niveles.
- Nivel 1: extensibilidad in-app (ABAP Cloud): para lógica ligera y muy acoplada al core: extensión de campos, validaciones sencillas, ajustes pequeños de interfaz. Se ejecuta dentro del propio S/4HANA, pero solo a través de ABAP Cloud, el modelo de desarrollo más reciente de SAP que limita a los desarrolladores a usar solo APIs publicadas, por diseño. ABAP Cloud es ya el estándar de SAP para todo desarrollo personalizado nuevo, lo que en sí mismo indica lo central que se ha vuelto.
- Nivel 2: extensibilidad side-by-side (SAP BTP): para lógica compleja, integraciones externas y todo lo que necesite evolucionar, escalar o fallar de forma independiente del core. Aquí debería aterrizar la mayor parte del desarrollo nuevo: con CAP para equipos pro-code, o SAP Build para low-code y desarrolladores ciudadanos, corriendo sobre Cloud Foundry o Kyma.
- Nivel 3: extensibilidad solo de interfaz (SAP Build): para dashboards personalizados, extensiones de Fiori y experiencias de front-end que no tocan lógica de negocio del core. Cada vez más, la gestionan directamente los usuarios de negocio, sin pasar por un equipo de desarrollo.
La regla de decisión es más sencilla de lo que parece por la taxonomía: si la lógica está muy acoplada a un objeto estándar de SAP y es de alcance pequeño, se queda in-app, vía ABAP Cloud. Si es compleja, necesita integrarse con sistemas que no son de SAP, o debería poder evolucionar en su propio ciclo de versiones, va side-by-side, en BTP. Equivocarse en esta secuenciación, ya sea usando extensibilidad in-app para lógica compleja o construyendo simples extensiones de campo como aplicaciones completas en BTP, es una de las causas más comunes, y más evitables, de que una iniciativa de clean core pierda impulso.
Gobierno: el riesgo del que nadie te avisa
Existe una versión de esta historia en la que una organización oye «mover todo a BTP» y lo interpreta como vía libre para que cada departamento monte su propia extensión, por su cuenta, sin ningún estándar compartido. Esa versión no produce un core limpio. Produce otro tipo de caos: una dispersión de servicios de BTP desconectados entre sí, componentes duplicados y un gasto de consumo cloud que se dispara. Deuda técnica con otra dirección, no deuda técnica eliminada.
La mitigación estándar, y la que conviene tener lista antes de poner en producción la primera extensión side-by-side, es un Cloud Center of Excellence (CCOE): un grupo pequeño y multidisciplinar que fija qué runtimes están aprobados, cómo se gestionan la identidad y la seguridad en todas las extensiones, cómo se monitoriza el consumo de BTP contra el presupuesto, y qué componentes se construyen una sola vez para reutilizarse, en vez de rehacerse en cada proyecto. Sin un CCOE, la extensibilidad side-by-side no evita la deuda técnica. Solo la traslada a una plataforma que tus procesos de gobierno de ABAP nunca se diseñaron para vigilar.
Aquí es también donde la conexión con el gobierno de IA del artículo de la semana pasada deja de ser abstracta. La respuesta de SAP a este mismo problema, a nivel de plataforma, es SAP AI Agent Hub, anunciado en Sapphire 2026 y previsto para disponibilidad general en el tercer trimestre del año, pensado para que TI pueda rastrear y auditar cada agente que opera en el entorno. Un CCOE para extensiones de BTP y una capa de gobierno para agentes de IA son, en la práctica, la misma disciplina aplicada a dos tipos de lógica autónoma que operan fuera de tu core: una es código, la otra razona sobre tus datos, y ambas necesitan el mismo tipo de supervisión.
Qué desbloquea realmente clean core
Es fácil plantear clean core solo como una forma de evitar riesgo. El enfoque más preciso es el de habilitador: clean core hace posibles varias cosas que un core personalizado impide por su propia naturaleza.
- Acceso el mismo día a las novedades: en un entorno clean core, las nuevas funciones de S/4HANA Cloud y las capacidades de IA se pueden usar casi el mismo día en que se lanzan. En un sistema muy modificado, cada novedad exige antes un ciclo de validación que los partners de SAP suelen situar entre tres y seis meses, antes de poder confiar en ella en producción.
- Agentes de IA que funcionan de verdad de fábrica: agentes estándar como el de gestión de caja, del artículo de la semana pasada, se construyen y se prueban contra flujos de proceso estándar de SAP. Sobre un entorno que cumple clean core funcionan tal cual se entregan. Sobre un entorno con variantes de proceso no estándar, ese mismo agente suele necesitar desarrollo a medida para cerrar la brecha, lo que erosiona en silencio el caso de ROI que justificó desplegarlo.
- Menor coste continuo, aunque la cifra exacta depende de tu punto de partida: las consultoras SAP que trabajan en muchas implementaciones clean core reportan un coste anual de mantenimiento y de servicios gestionados sensiblemente menor en entornos clean core frente a los muy modificados, con cifras que según la fuente rondan entre el 25% y el 40%. Trata cualquier cifra concreta como orientativa y específica de la cartera de clientes de esa consultora, no como una garantía, y pide a cualquier partner que te muestre su propia metodología antes de construir un caso de negocio sobre ese número.
- Integración más rápida de cualquier novedad: adquisiciones, nuevas unidades de negocio y nuevas entidades regionales se incorporan más rápido sobre un entorno clean core, porque el trabajo de integración es aditivo (nuevas extensiones, nuevas conexiones API) en lugar de exigir primero un análisis de qué personalizaciones existentes podrían chocar con los procesos de la nueva entidad.
Qué significa esto para los CIOs
Para un CIO, clean core es a la vez un programa técnico y un programa de gobierno. De ahí salen cinco implicaciones directas:
- Trata ABAP Cloud como el camino por defecto, no como la excepción: para cualquier petición de desarrollo nuevo, la suposición de partida debería ser ABAP Cloud o una extensión side-by-side en BTP, no la modificación clásica del core. Que modificar el core sea la excepción que necesita una aprobación explícita, no el camino de menor resistencia.
- Monta el CCOE antes de que crezca tu huella en BTP: es mucho más fácil hacerlo con cinco extensiones en producción que con cincuenta. Esperar a que la dispersión ya sea un problema visible significa montar el gobierno a posteriori sobre sistemas que se construyeron sin él, un ejercicio bastante más difícil que hacerlo desde el principio.
- Convierte la evaluación de código personalizado en un proyecto propio y financiado: usa la herramienta Custom Code Migration de SAP, o su equivalente de un partner, para inventariar cada objeto personalizado y clasificarlo: retirar, remediar a ABAP Cloud o mover a BTP. Esto convierte un «deberíamos limpiar el core en algún momento» en un programa real, acotado y presupuestado.
- Encaja clean core dentro de la migración, no después: como defendía el artículo de la semana pasada, incorporar clean core a posteriori en un sistema que ya salió en vivo con personalizaciones recién creadas es un ejercicio bastante más caro y más difícil que construirlo desde el principio. Si todavía tienes la migración por delante, este es el momento de mayor palanca para acertar con la secuencia.
- Convierte la calidad del código personalizado en una métrica monitorizada, no en una auditoría puntual: herramientas como SAP Cloud ALM pueden señalar de forma continua las violaciones de clean core antes de que bloqueen una actualización. Clean core es una disciplina que hay que mantener versión tras versión, no un proyecto con fecha de fin.
Qué significa esto para los CFOs
Para un CFO, la conversación de clean core suele llegar disfrazada de partida de gasto en licencias de BTP. Merece la pena replantearla antes de que llegue al consejo:
- Esto es una decisión de coste total de propiedad, no de licencias: el gasto en consumo de BTP es visible y está desglosado, lo que lo convierte en un blanco fácil para recortar. El coste de no hacerlo (ciclos de revalidación trimestrales, agentes de IA que necesitan desarrollo a medida, integraciones de M&A más lentas) es real pero está repartido en muchas partidas, lo que hace fácil infravalorarlo si solo se compara un año. Pide una comparación de coste total a varios años, no una comparación de licencias de un solo ejercicio.
- Financia la evaluación de código personalizado aunque no financies nada más este ciclo: es la forma más barata y rápida de convertir una conversación abstracta sobre deuda técnica en una lista de tareas concreta, priorizada y con cifras reales. La mayoría de las organizaciones subestima cuánto de su código personalizado se puede simplemente retirar, en vez de migrar, en cuanto alguien lo inventaría de verdad.
- Conecta esto directamente con la conversación de presupuesto de IA de la semana pasada: si finanzas está financiando pilotos de IA agéntica sin un flujo de trabajo paralelo de clean core, ese presupuesto de IA corre el riesgo real de financiar pilotos que nunca llegan a escalar, por las mismas razones de arquitectura descritas en aquel artículo. Estas dos partidas de presupuesto deberían revisarse juntas, no por separado.
- Espera que el ahorro se note en capacidad liberada, no en una línea de coste que baja: en línea con el planteamiento realista de ROI de IA de la semana pasada, el retorno financiero de clean core se nota sobre todo en menos horas de consultoría dedicadas a validación y retrabajo, no en una reducción inmediata de una partida concreta. Construye el caso de negocio sobre esa realidad, no sobre una cifra más grande pero menos creíble.
Cómo se ve «bien hecho»: un modelo de madurez sencillo
Igual que con la adopción de IA, la madurez en clean core sigue un patrón reconocible en los programas S/4HANA, y la mayoría de las organizaciones pueden ubicarse con honestidad en cinco minutos.
- Etapa 1: sin control: modificar el core sigue siendo el camino por defecto para el desarrollo nuevo, porque es el camino de menor resistencia y nadie ha dicho lo contrario. No hay inventario de objetos personalizados, no hay CCOE, y cada actualización trimestral de S/4HANA Cloud se trata como un pequeño proyecto en vez de como algo rutinario. Describe a buena parte del parque instalado, incluidas muchas organizaciones que migraron a S/4HANA hace relativamente poco.
- Etapa 2: consciente pero sin presupuesto: la dirección sabe que hay un problema, puede que incluso haya una diapositiva sobre clean core en el plan de IT del año pasado, pero no hay presupuesto propio, no hay un responsable con nombre, y ABAP Cloud se usa de forma irregular según qué desarrollador coja el ticket. Es la etapa más común, y también en la que más fácil es quedarse atascado de forma indefinida, porque ser consciente sin financiar no produce ningún cambio visible.
- Etapa 3: gobernada y en marcha: ya se completó una evaluación de código personalizado, existe un CCOE con autoridad real, ABAP Cloud o BTP side-by-side es el estándar obligatorio para el trabajo nuevo, y la deuda técnica existente se va reduciendo siguiendo una lista priorizada, no una aspiración. Las actualizaciones trimestrales empiezan a ser más rápidas y más baratas, aunque todavía no rutinarias.
- Etapa 4: clean core como estado por defecto: las nuevas capacidades de S/4HANA y los agentes de IA se activan casi el mismo día del lanzamiento, porque no hay nada fuera de estándar con lo que puedan chocar. El inventario de código personalizado es un panel vivo, vigilado con herramientas como SAP Cloud ALM, no un informe puntual que queda desactualizado en un trimestre. Hoy es una minoría muy pequeña del parque instalado, y la distancia se agranda con el tiempo: cada trimestre que pasa, las organizaciones en Etapa 4 lo dedican a lanzar novedades, mientras el resto lo dedica a validar.
La mayoría de quienes lean esto están en algún punto entre la Etapa 1 y la Etapa 2. La pregunta útil no es «cómo llegamos a la Etapa 4», que es una respuesta a varios años vista que invita a posponerla indefinidamente. Es «qué hace falta para llegar a la Etapa 3», que es un programa acotado y financiable, con un responsable claro y un primer entregable concreto: la evaluación de código personalizado.
Tres objeciones que merece la pena tomarse en serio
- «¿Clean core no es solo una forma de que SAP y sus partners vendan más licencias de BTP?»: Una objeción legítima, y que conviene aplicar a cualquier recomendación de arquitectura ligada a un proveedor, esta incluida. La respuesta honesta: el consumo de BTP es un coste real e incremental, y cualquier partner que lo recomiende debería poder mostrar una comparación de coste total, no solo una cotización de licencias. Lo que sostiene el argumento de fondo, al margen de quién lo venda, es el ritmo trimestral de versiones: los clientes de SAP Cloud están sujetos a un ciclo de actualización obligatorio, elijan la extensibilidad que elijan, y un core limpio es lo que hace que ese ciclo salga barato en vez de caro. Esa parte del argumento no depende en absoluto del precio de BTP.
- «Nuestro entorno tiene veinte años de personalización. Clean core no es realista para nosotros.»: Casi nunca es realista como un proyecto único con fecha de fin, y tratarlo así suele ser justo lo que hace que estas iniciativas se estanquen. Sí es realista como disciplina continua, aplicada primero al desarrollo nuevo (dejar de sumar deuda) y después a las personalizaciones existentes de mayor valor o mayor riesgo (empezar a reducir la deuda donde más importa), en vez de intentar remediar dos décadas de ABAP en un único programa. Una evaluación de código personalizado, mencionada antes en la sección de CIOs, es lo que convierte «no realista» en una lista priorizada y secuenciada.
- «No tenemos el talento SAP necesario para hacer esto bien.»: Es una limitación legítima, y es el mismo problema de talento que el artículo de la semana pasada señalaba como el reto más urgente para los CFOs, solo que aparece en otro departamento. Las herramientas han avanzado más de lo que la mayoría de las organizaciones ha notado: los partners de SAP reportan que el desarrollo asistido por IA dentro de SAP Business Application Studio, usando Joule, ya puede generar buena parte del código repetitivo de una extensión típica de BTP a partir de una descripción en lenguaje natural. Eso cambia el perfil que necesita un equipo de clean core: de «experto profundo en ABAP» a «persona que entiende el proceso de negocio y sabe validar lo que generó la IA». Es una contratación bastante más sencilla.
Una checklist de preparación
Antes de comprometer presupuesto en una iniciativa de clean core, o de dar por hecho que tu plan de migración actual ya lo cubre, repasa estas preguntas:
- ¿Sabes, con un inventario real y no con una estimación, cuánto código personalizado hay hoy en tu core, y qué parte modifica directamente objetos estándar de SAP?
- ¿Hay un responsable, una persona concreta, no un comité, que rinda cuentas por el cumplimiento de clean core igual que hay un responsable de seguridad o del cierre financiero?
- ¿El desarrollo nuevo va por defecto a ABAP Cloud o a BTP side-by-side, o sigue yendo al patrón con el que el desarrollador de turno se sienta más cómodo?
- ¿Existe un CCOE, o un órgano de gobierno equivalente, antes de que tu número de extensiones en BTP empiece a crecer, y no después?
- Si tu migración a S/4HANA todavía está por delante, ¿clean core está escrito en el diseño técnico y en el flujo de datos, o es una diapositiva del kickoff que nadie vuelve a mirar?
Por qué esto conecta directamente con el plazo de 2027
Clean core y el plazo de mantenimiento estándar de SAP ECC de diciembre de 2027 no son dos iniciativas separadas compitiendo por el mismo presupuesto. Para cualquier organización que todavía esté migrando, son el mismo programa visto desde dos ángulos. Como se mencionaba en el artículo de la semana pasada, una parte importante de los directivos de empresa, algunas cifras superan el 40%, dice priorizar hoy la hoja de ruta de innovación en IA de SAP por encima del propio plazo de mantenimiento como su motivo real para migrar. Clean core es el requisito de arquitectura para que esa hoja de ruta de IA entregue algo. Tratarlo como un flujo de trabajo paralelo y de menor prioridad que la migración malinterpreta por qué se está migrando.
Para las organizaciones que ya migraron a S/4HANA sin disciplina de clean core, la posición es menos cómoda pero no infrecuente: describe a buena parte del parque instalado. La evaluación de código personalizado descrita más arriba funciona exactamente igual en modo retroactivo que dentro de una migración en marcha; simplemente parte de un sistema que ya está en producción, en vez de un sistema todavía en diseño. El coste de empezar ahora es real. El coste de esperar un año más se acumula, en el sentido literal descrito antes en este artículo.
La conclusión
Clean core suena a tarea técnica de limpieza, y ese planteamiento es justo la razón por la que tantas organizaciones invierten menos de lo que deberían en ello. Se entiende mejor como el requisito de arquitectura para casi todo lo demás en la hoja de ruta actual de SAP: agentes de IA que funcionan de forma fiable, ciclos de actualización que no exigen un simulacro de incendios cada trimestre, integraciones que no se rompen con el siguiente cambio de esquema, y adquisiciones que se incorporan en meses en vez de años.
Las organizaciones que traten esto como una disciplina continua y gobernada, no como un proyecto de limpieza puntual, van a poder usar de verdad lo que SAP lance en 2026 y 2027 sin pagar un impuesto de seis meses de validación en cada versión. El resto seguirá pagando ese impuesto de forma indefinida, y lo llamará el coste de trabajar con SAP, cuando en realidad es el coste de una decisión de arquitectura tomada, o evitada, años atrás.
¿Quieres una lectura honesta de cómo de limpio está realmente tu core? Ofrecemos una conversación gratuita de 30 minutos sobre preparación para IA y Clean Core, sin discurso comercial, solo dónde estás y cuál es el siguiente paso realista. Más información en theintelligenthub.com.
Fuentes
- SAVIC Technologies, «SAP Clean Core in 2026: Why It’s No Longer Optional, And How to Get There», 17 abr. 2026 — https://www.savictech.com/insights/sap-clean-core-strategy-2026/
- Kellton, «The Definitive Guide to SAP BTP Side-by-Side Extensions in 2026», 28 abr. 2026 (act. 5 may. 2026) — https://www.kellton.com/kellton-tech-blog/sap-btp-side-by-side-extension-guide
- ERP Today, «SAP Sapphire 2026: SAP Business AI Platform Consolidates SAP BTP Stack to Solve Enterprise AI Fragmentation» — https://erp.today/sap-business-ai-platform-consolidates-sap-btp-stack-to-solve-enterprise-ai-fragmentation/
- Kagool, «SAP S/4HANA Finance Transformation: A Strategic Guide for Enterprise Leaders in 2026» — https://kagool.com/sap-s-4hana-finance-transformation-a-strategic-guide-for-enterprise-leaders-in-2026/
Nota: las cifras sobre adopción de BTP, herramientas de extensibilidad y ahorro de coste vienen de blogs de consultoras y partners de SAP (SAVIC, Kellton), no de una comunicación auditada de forma independiente por SAP. Donde una cifra es propia de la cartera de clientes de una consultora concreta (por ejemplo, los rangos de ahorro en AMS), se marca como orientativa en el texto y no como una garantía válida para todo el sector.
Relacionado
¿Estás evaluando tu propio programa de transformación SAP? Explorar Asesoría →
¿Tienes una brecha de habilidades concreta en tu programa S/4HANA? Explorar Sourcing de Talento →
¿Quieres ver el panorama completo? Explorar la serie completa →