SAP a Snowflake: 8 preguntas antes de comprometer presupuesto

La mayoría de los proyectos de SAP a Snowflake que se atascan no fallaron en la ejecución: fallaron en el alcance, porque nadie hizo estas preguntas antes de cotizar. Son ocho, se contestan en una sesión con el equipo de SAP, y cada una cambia el diseño o el presupuesto.

Si estás evaluando proveedores, sirven también como filtro: una propuesta que no toca estos puntos está cotizando plomería, no un proyecto de datos.

1. ¿Qué versión de SAP es, exactamente?

La pregunta: ¿ECC, S/4HANA o BW? ¿Y hay más de un sistema?

Por qué importa: no son intercambiables. S/4HANA cambió estructuras que en ECC llevaban veinte años estables — el caso más citado es la consolidación de tablas en finanzas. Un diseño hecho para ECC no se traslada tal cual.

Respuesta aceptable: la versión y el nivel de parche, por escrito. Y si hay un plan de migración a S/4HANA en los próximos dos años, eso cambia la decisión de arquitectura hoy: conviene apoyarse en mecanismos que sobrevivan la migración, como vistas CDS y ODP, en lugar de leer tablas que van a desaparecer.

2. ¿Qué módulos y qué objetos de negocio, concretamente?

La pregunta: no “necesitamos datos de SAP”, sino qué decisión de negocio y qué objetos la alimentan.

Por qué importa: si la lista incluye finanzas —partidas contables, documentos— entran las tablas cluster, y eso descarta el acceso directo a la base de datos y limita los conectores genéricos. Si es solo maestros de materiales y clientes, el problema es mucho más simple.

Respuesta aceptable: una lista de objetos de negocio con el área que los va a usar. Si nadie puede nombrarlos, el proyecto todavía no está listo para cotizarse.

3. ¿Cuáles son los volúmenes reales, con histórico?

La pregunta: número de registros por tabla principal, incluyendo el histórico completo, y crecimiento mensual.

Por qué importa: la diferencia entre 2 millones y 200 millones de registros no es de grado, es de diseño. Define si la carga completa es viable, cuánto cómputo vas a consumir en Snowflake y si la ventana de proceso alcanza.

Respuesta aceptable: conteos reales del sistema productivo, no del de calidad. Es el dato que más se pide con el número del ambiente de pruebas y luego sorprende en producción.

4. ¿Qué frescura necesita cada objeto?

La pregunta: ¿qué decisión cambia si el dato llega en 15 minutos en lugar de mañana?

Por qué importa: perseguir tiempo real donde no se necesita infla el costo y la complejidad sin cambiar ninguna decisión. Y hay un límite estructural: si el proceso de negocio cierra por lote en la madrugada, el dato no está completo antes, sin importar con qué frecuencia lo extraigas.

Respuesta aceptable: una frescura por objeto, no una global. Diaria para la mayoría, más frecuente solo donde alguien actúa en minutos.

5. ¿Existe un mecanismo delta para esos objetos?

La pregunta: ¿hay extractores DeltaQ o ODP disponibles? ¿Las tablas tienen campo de modificación confiable? ¿Cómo se van a detectar los borrados?

Por qué importa: es la pregunta que más presupuesto mueve y la que menos se hace. Si el delta hay que construirlo a mano, ahí se va la mayor parte del mantenimiento futuro. Y los borrados son el punto ciego: un registro eliminado no aparece en un filtro por fecha, así que se queda para siempre en Snowflake y con el tiempo produce totales que no cuadran contra SAP.

Respuesta aceptable: un mecanismo delta identificado por objeto y una estrategia explícita para borrados. El detalle está en carga incremental de SAP a Snowflake.

6. ¿Cómo va a acceder la herramienta a SAP?

La pregunta: ¿a través de las interfaces de la aplicación (RFC, BAPIs, extractores) o directo a la base de datos?

Por qué importa: el acceso directo salta la seguridad de SAP, no puede leer tablas pool ni cluster, y depende de estructuras internas que SAP puede cambiar sin aviso. Si un proveedor propone leer la base directo, eso es una señal de alerta, no una optimización.

Respuesta aceptable: interfaces soportadas por SAP, con un usuario de servicio dedicado y permisos mínimos. Las razones técnicas completas están en por qué extraer datos de SAP es difícil.

7. ¿Qué dice tu contrato de SAP sobre esto?

La pregunta: ¿el acceso a datos que planeamos tiene implicaciones de licenciamiento?

Por qué importa: las condiciones de acceso indirecto o digital son un tema contractual, no técnico, y varían según el acuerdo de cada empresa.

Respuesta aceptable: una revisión con tu área de compras o legal y, si hay duda, con tu representante de SAP. Ningún proveedor de integración —nosotros incluidos— puede darte esa respuesta, y quien te diga que no hay nada que revisar está opinando sobre un contrato que no ha leído. Vale la pena resolverlo antes de firmar, no después.

8. ¿Quién lo mantiene en dos años?

La pregunta: cuando quien lo implementó no esté, ¿quién agrega una tabla nueva?

Por qué importa: es la pregunta que determina el costo total real. Una integración construida con desarrollo ABAP a la medida se convierte en caja negra cuando esa persona cambia de trabajo. Una configuración declarativa la puede modificar quien llegó después.

Respuesta aceptable: configuración declarativa en lugar de código, documentación de qué extrae cada proceso, y una persona interna que entienda el diseño — no solo el proveedor.

Las dos preguntas que revelan a un mal proveedor

Además de las ocho, dos que sirven de filtro:

“¿Cómo van a manejar los borrados?” Si la respuesta es vaga o “eso normalmente no es problema”, no han hecho esto en producción con volúmenes reales.

“¿Qué pasa con las tablas cluster?” Si no saben a qué te refieres, o dicen que se leen normal desde la base de datos, no conocen SAP.

La señal de alerta más importante

Si una propuesta habla solo de conectar y mover datos, y nunca menciona el modelado ni las definiciones de métricas, está cotizando la mitad del proyecto.

Aterrizar datos de SAP en Snowflake no produce valor por sí solo. El valor aparece cuando esos datos tienen una definición única por métrica y alguien decide con ellos. Sin esa capa terminas con una copia más ordenada del mismo desorden — es la parte que explicamos en qué es una capa semántica.

Y una recomendación sobre el alcance

No cotices todo SAP. Elige un dominio —cobranza, inventario, ventas— llévalo completo hasta que alguien decida con él, y usa ese resultado para financiar el siguiente. El primer dominio es el más lento porque incluye construir el cimiento; los siguientes bajan de forma notable porque reutilizan la extracción, el modelo y el gobierno.

Si un proveedor te cotiza todos los dominios al mismo precio, no está aprovechando lo que ya construyó.

Las cinco formas de hacer la extracción, comparadas, están en cómo llevar datos de SAP a Snowflake.

---

En EGOS BI hacemos pruebas de concepto acotadas sobre un dominio antes de comprometer un proyecto completo, con Theobald hacia Snowflake. Si quieres contestar estas ocho preguntas con acompañamiento, agenda una sesión.