Cómo PUMA sacó sus datos de SAP for Retail con Theobald

Este es un caso público publicado por Theobald Software, no un proyecto nuestro. Lo traemos aquí porque es uno de los pocos casos de integración de SAP documentados con suficiente detalle técnico como para aprender algo concreto, y porque el problema que resuelve es exactamente el que llega a nuestra puerta: una empresa con SAP en varias regiones que necesita reportería confiable sin desarrollar la extracción a mano.

La fuente original está al final. Lo que sigue son los hechos que Theobald declara, y después nuestra lectura de qué se puede trasladar a un proyecto propio.

El contexto declarado

PUMA SE —fundada en 1948 en Herzogenaurach, Alemania, con más de 10,000 empleados y productos distribuidos en más de 120 países— operaba SAP ERP 6.0 con la solución de industria SAP for Retail.

La necesidad, tal como la describe el caso: integrar los datos de SAP hacia Microsoft SQL Server de forma rápida, confiable y automática, para alimentar la reportería de dirección en el procesamiento de pedidos, que corría sobre SQL Server Reporting Services y Analysis Services.

Es un planteamiento reconocible. No es “queremos hacer inteligencia artificial”: es que la información de pedidos vive en SAP, el análisis vive en otra plataforma, y mover una a la otra de forma automática resultó ser el problema difícil.

Qué se implementó

Theobald declara que PUMA evaluó el conjunto de componentes de Xtract IS tras una investigación de proveedores, y eligió dos:

• El componente Table, para transferir datos masivos directamente desde tablas de SAP.
• DeltaQ, para aprovechar los mecanismos de extracción delta propios de SAP.

La extracción se integró directamente en SQL Server Integration Services, es decir, dentro del flujo ETL que la empresa ya operaba, en lugar de como una herramienta aparte.

Alcance de la primera etapa: los sistemas SAP ERP de tres regiones distintas.

Según el caso, lo que decidió la elección fueron tres cosas: la madurez de las interfaces, la facilidad de operación y la relación precio-desempeño.

Lo que declara el cliente

Dos citas, ambas atribuidas a Rainer Erras, Senior Developer de IT Business Intelligence Solutions en PUMA SE:

“Los tiempos de respuesta cortos nos dan una ventaja competitiva significativa. Xtract IS contribuye de forma importante a eso.”

“No se perdió información de ninguna manera. Los extractores además son muy estables y todavía no hemos experimentado una falla.”

La segunda cita es la que más dice técnicamente, y por una razón que no es obvia: “no se perdió información” es la afirmación más difícil de sostener en una extracción de SAP. No es una cortesía — es exactamente el punto donde fallan los enfoques hechos a mano, y volvemos a eso más abajo.

La elección de DeltaQ es el detalle que importa

De todo el caso, la decisión más significativa es haber usado DeltaQ además del componente de tablas. Vale la pena explicar por qué.

Recargar todo cada noche funciona perfectamente en las pruebas y deja de funcionar cuando entra el histórico completo con volúmenes reales. Entonces aparece la pregunta de la carga incremental, y con ella el problema de fondo: SAP no tiene una forma única de saber qué cambió. Depende de la tabla y del objeto.

Algunas tablas tienen campos de fecha de modificación que sirven como marca de agua. Otras no tienen ninguna forma confiable de detectar cambios. Y los borrados son el punto ciego: un registro eliminado no aparece en un filtro por fecha, así que se queda para siempre en el destino y con el tiempo produce totales que no cuadran contra SAP.

DeltaQ usa los mecanismos delta que SAP ya provee, en lugar de que alguien los reconstruya. Ahí está la conexión con la cita: cuando la lógica delta se construye a mano, “no se perdió información” es justo lo que no se puede afirmar. El detalle completo está en carga incremental de SAP a Snowflake y en por qué extraer datos de SAP es difícil.

Lo que sí se traslada a un proyecto propio

Cuatro cosas, y ninguna depende de que tengas el tamaño de PUMA.

1. Empezar por un alcance acotado. Tres regiones en la primera etapa, no todos los sistemas de golpe. Es el mismo principio que aplicamos por dominio: un alcance que se puede entregar y demostrar, y que financia el siguiente.

2. Integrar la extracción en el flujo que ya existe. PUMA metió la extracción dentro de SSIS en lugar de operar una plataforma paralela. Una herramienta menos que administrar es una decisión de arquitectura, no de comodidad.

3. Resolver el delta desde el diseño, no cuando duela. Es la diferencia entre un proyecto que sobrevive dos años y uno que se vuelve caja negra.

4. Evaluar los tipos de extracción que realmente necesitas. El caso menciona Table y DeltaQ porque eso cubría su necesidad. Si tu lista incluye finanzas, entran las tablas cluster —BSEG y compañía— y eso cambia el requisito. Las cinco opciones comparadas están en cómo llevar datos de SAP a Snowflake.

Las advertencias honestas sobre este caso

Tres, y conviene decirlas de frente:

Es un caso publicado por el proveedor. Los aspectos que se destacan son los que el proveedor eligió destacar. No hay auditoría independiente, ni menciona el costo total, ni el tiempo real del proyecto completo.

Es un caso de hace varios años, con un destino distinto al de hoy. Los ingresos que cita el material corresponden a 2014, y el destino es SQL Server con SSIS — que era el stack analítico razonable de esa época. Hoy la misma necesidad se resuelve normalmente hacia una Data Cloud, y el producto equivalente es Xtract Universal, que tiene Snowflake como destino nativo. Cómo funciona esa versión está en Xtract Universal: cómo funciona la extracción de SAP a Snowflake.

El caso no dice nada sobre modelado ni definiciones de métricas. Y eso es la mitad del trabajo: aterrizar datos de SAP en un destino no produce valor por sí solo. El valor aparece cuando esas cifras tienen una definición única por métrica y alguien decide con ellas.

Qué preguntaríamos antes de replicarlo

Si este caso se parece a tu situación, las preguntas que ordenan la conversación son las mismas de siempre: qué versión de SAP exactamente, qué módulos y objetos de negocio, volúmenes reales con histórico, qué frescura necesita cada objeto, si existe mecanismo delta por objeto, cómo va a acceder la herramienta, qué dice tu contrato de SAP, y quién lo mantiene en dos años.

Las ocho, con la respuesta que deberías considerar aceptable en cada una, están en 8 preguntas antes de comprometer presupuesto.

---

En EGOS BI usamos Theobald como puente entre SAP y arquitecturas modernas, con Snowflake como destino y la analítica encima en Tableau u Omni. PUMA es un caso público de Theobald, no un cliente nuestro; si quieres saber cómo se ve este trabajo en tu SAP, agenda un diagnóstico.

Fuente: Theobald Software — Success Story: SAP Data Integration for PUMA with Xtract IS