
Closing the SAP Data Gap: A CIO’s Guide to Clear, Connected Data

Sean Antonello
Arquitecto Jefe de Soluciones SAP
Sean Antonello
Arquitecto Jefe de Soluciones SAPMay 1, 2026 | 5 Minuto(s) de lectura
La mayoría de los CIO se enfrentan a la misma tensión en estos momentos. Hay presión para modernizar, añadir capacidad de IA y sacar más partido de los datos SAP, pero siempre existe el riesgo de desestabilizar los sistemas centrales sobre los que funciona toda la empresa. Es una tensión real, y la forma en que las organizaciones suelen intentar resolverla a menudo empeora las cosas.
El error más común
Históricamente, las organizaciones creaban procesos personalizados directamente dentro de su ERP central. En la era de ECC, esa era esencialmente la única opción. Con S/4HANA, se dispone de un modelo diferente, construido en torno al concepto de núcleo limpio, pero muchas organizaciones siguen recurriendo por defecto a los viejos patrones.
El problema se manifiesta de dos maneras. O bien las personalizaciones se siguen creando directamente dentro del ERP central, o bien se están creando en un sistema completamente independiente que no tiene conectividad real con SAP. En ambos casos se produce el mismo resultado: los equipos dedican mucho tiempo a gestionar la integración y a hacer que los procesos desconectados funcionen juntos.
Qué significa realmente Clean Core
Actualmente se habla mucho del núcleo limpio, pero lo que significa en la práctica es sencillo. Las personalizaciones no deberían vivir dentro del núcleo del ERP. Ralentizan las cosas, hacen que los sistemas sean más engorrosos y, lo que es más visible, hacen que los ciclos de actualización sean largos y dolorosos. Cuanta más personalización haya en el núcleo, más trabajo requerirá una actualización.
El enfoque recomendado por SAP consiste en crear esas personalizaciones en BTP, la plataforma tecnológica empresarial. Todo en SAP Business Suite, incluyendo S/4HANA y Business Data Cloud, se asienta sobre BTP. Permite la integración, el desarrollo de aplicaciones personalizadas y sin código dentro del ecosistema SAP, y conexiones estándar entre sistemas.
El beneficio práctico es significativo. Cuando se desarrolla en BTP en lugar de en el núcleo, una actualización de S/4 no afecta en absoluto a esos procesos. Se reduce la deuda técnica dentro del ERP central, se simplifican los ciclos de actualización y se evitan los bloqueos que impiden a los usuarios realizar sus propios servicios mientras se está realizando una actualización. También hay un aspecto relacionado con las licencias: si los usuarios acceden a S/4 sólo porque un flujo de trabajo personalizado vive allí, mover ese flujo de trabajo a BTP elimina por completo la necesidad de esos puestos.
Un ejemplo real: El portal de proveedores xi.Orion
Improving ha creado un portal llamado xi.Orion para dar soporte a las relaciones con vendedores y proveedores. El escenario que aborda es común: equipos de cara al cliente que reciben un flujo constante de preguntas de los proveedores sobre el estado de pago de facturas, solicitudes de compra y órdenes de compra. Se trata de una interacción de gran volumen y escaso valor que consume un ancho de banda interno considerable.
xi.Orion se construyó dentro de BTP, siguiendo el enfoque de núcleo limpio. Los proveedores pueden autoservirse, cargar una solicitud de compra (PR) o un pedido de compra (PO), utilizar Joule, la IA de SAP, para preguntar por el estado de aprobación de la PR o el PO y comprobar cuándo se van a pagar las facturas. Cuando un proveedor envía una solicitud de pedido directamente a través del portal, se inicia un flujo de trabajo de aprobación sin que los usuarios externos entren en contacto con el ERP central. Esto también crea un entorno más seguro, ya que los proveedores no tienen acceso al sistema interno.
Se sustituye el proceso de correo electrónico de ida y vuelta. Se reduce la carga de trabajo de los equipos internos. Y nada de esto requiere personalizar S/4HANA.
Dónde encajan Fabric, Databricks y Snowflake
Ni siquiera las tiendas SAP utilizan SAP en su totalidad. SAP lo ha reconocido, y el ecosistema se ha abierto significativamente. Business Data Cloud incluye ahora conectores estándar a sistemas no SAP para datos operativos, con acceso directo a Databricks, Snowflake y Microsoft Fabric. Se espera que en la segunda mitad de este año se generalice la disponibilidad de Fabric con un enfoque de copia cero.
Lo que esto significa para un CIO es flexibilidad. Puede mantener intacta su inversión en SAP, conservar la capa semántica y las relaciones de datos maestros que viven dentro de SAP, y seguir uniendo esa información con datos operativos de fuera de la red SAP. Esta combinación de datos SAP ricos y centrados en la empresa con datos operativos externos ha sido históricamente difícil de conseguir. Las herramientas actuales la hacen mucho más accesible.
Qué hacer si está a mitad de migración
Para las organizaciones que se encuentran en medio de una migración a S/4HANA, hay dos cosas que merece la pena abordar antes de que la migración avance demasiado.
El primero es el núcleo limpio. Puede parecer algo de lo que hay que ocuparse más tarde, pero a menudo es más rentable trasladar los procesos personalizados a BTP durante la migración que después. Identificar con antelación los procesos más pesados y planificar su traslado fuera del núcleo antes de la puesta en marcha es una mejor manera de aprovechar el momento.
El segundo son los datos y el análisis, que suelen tratarse como algo secundario en las migraciones de ERP. Las organizaciones se ponen en marcha y luego descubren que sus usuarios no tienen informes ni una estrategia de informes definida. Definir el programa de datos y análisis en una fase temprana, antes de la puesta en marcha, significa que los usuarios tienen listos los informes que necesitan desde el primer día.
Cómo son dieciocho meses de progreso
Con una hoja de ruta clara, una organización que lleve dieciocho meses en esta tarea tendría S/4HANA en funcionamiento con los servicios de BTP gestionando la integración, sustituyendo al antiguo middleware como PI/PO. La filosofía de núcleo limpio estaría en práctica, con procesos personalizados trasladados a aplicaciones BTP. Business Data Cloud conectaría los datos operativos de un almacén o lago de datos de su elección a los datos de SAP, con SAP Analytics Cloud para la elaboración de informes y previsiones.
El resultado son informes de autoservicio en toda la organización, planificación y previsión que se ejecutan de forma más automatizada, y un núcleo materialmente más limpio. El objetivo es completar el bucle: entrada de datos limpios, salida de inteligencia y nada roto en el medio.
¿Listo para empezar?
Improving ayuda a los CIO a navegar por la modernización de SAP, adoptar prácticas de núcleo limpio y crear un entorno de datos conectado que respalde tanto las operaciones como los análisis. Tanto si se encuentra a mitad de la migración como si está pensando en lo que viene a continuación, hablemos de por dónde empezar.