SAP S/4HANA · AWS · Inteligencia de Ventas
Este es el viaje que recorre cada venta: nace en SAP, se depura capa por capa y llega convertida en indicadores confiables a tus tableros. Sin tocar tu SAP productivo.
El recorrido en 3 grandes bloques
No necesitas ser técnico para entenderlo. Sigue el dato: de dónde viene, cómo se limpia y en qué se convierte cuando llega a tus manos.
El proceso comercial que ya conoces en SAP: del pedido a la factura.
La estrategia Medallion: el dato sube de bronce a plata y a oro.
Indicadores confiables, idénticos en QuickSight y Power BI.
Bloque 1 · De dónde vienen los datos
Cada venta deja una huella en SAP: un pedido, una entrega, una factura. Nosotros leemos esa huella sin interrumpir tu operación y la llevamos a AWS para trabajarla. SAP sigue siendo la fuente; AWS hace el análisis.
El cliente ordena
VBAK · VBAPSale la mercadería
LIKP · LIPSSe cobra la venta
VBRK · VBRPTodo queda enlazado
VBFA · flujoLeemos en ventanas de baja carga, solo lectura, sin abrir SAP a internet. Tu productivo no se toca en cada consulta.
El dato viaja por red privada hacia AWS. Credenciales protegidas, todo cifrado de extremo a extremo.
Una carga inicial completa y luego solo lo que cambia. Tus tableros reflejan la realidad del negocio.
Bloque 2 · La estrategia Medallion
El dato crudo de SAP no sirve para decidir tal cual: viene en códigos, sin nombres, sin contexto. Lo hacemos subir por cuatro capas. En cada una queda más limpio, más completo y más entendible, hasta llegar al oro: información lista para el negocio.
Tal como salen de SAP. Sin tocar.
Tipos, fechas y textos ordenados.
Sin duplicados, todo conectado.
Con nombres, KPIs y contexto.
Mira cómo cambia un mismo registro al subir:
No contamina el resto. Se aparta en una zona de cuarentena y queda auditado. Solo el dato confiable llega al oro.
Bloque 3 · Qué llega a los tableros
Sobre la capa de oro construimos una única fuente de verdad: las vistas de negocio. De ahí beben todos los tableros. Un indicador se define una sola vez y se ve igual en todas partes.
Misma fórmula, mismo número. Sin discusiones sobre "de dónde salió esa cifra".
Margen por zona geográfica, organización de ventas y desempeño regional.
Abrir tableroLos tableros abren en Amazon QuickSight y requieren acceso autorizado. En vivo se presentan con una sesión iniciada.
Para quienes quieren el detalle
Hasta aquí, la historia. Si quieres ver la ingeniería que la sostiene, aquí está: la arquitectura completa, cómo se carga y se mantiene el dato, y de dónde sale exactamente cada cifra. Explora lo que te interese; no hace falta leerlo todo.
Toca cualquier componente para ver qué hace, en simple y en técnico.
Toca cualquier caja del diagrama para ver qué hace, explicado en simple.
Dos capas de acceso, cada una donde rinde mejor: la capa ABAP (RFC / OData) y la capa masiva (HANA JDBC). Aquí el sustento de la decisión.
Principio rector: SAP no se consulta cada vez que abres un tablero. SAP es la fuente; AWS es la plataforma de análisis. Extraemos una vez, analizamos muchas. Así tu SAP productivo nunca carga el peso de los reportes.
RFC · OData
Camino por defecto
Entra "por la puerta" de la aplicación: RFC (BAPI / módulos Z, vía pyrfc) y OData (servicios REST sobre CDS Views).
Se usa para: el día a día transaccional de SD (pedidos, entregas, facturas) y entidades expuestas como servicio.
HANA JDBC · hdbcli
Cargas masivas
Lee directamente la base de datos HANA con un usuario de solo lectura.
Se usa para: la carga histórica inicial (millones de filas) y reconciliación.
No importa. El pipeline es el mismo desde que el dato entra al lago. Cambiar entre la capa ABAP (RFC/OData) y la capa masiva (JDBC) no rediseña la plataforma.
Aquí vive la lógica de negocio. Vale la pena entender el qué, el cuándo y el por qué de cómo está construida.
Cada quien filtra y calcula distinto. La reunión se va en discutir de dónde salió el número.
La fórmula se define una vez. Todos ven el mismo número. La reunión se va en decidir, no en discutir.
Cada indicador tiene una definición empresarial única: qué mide, cómo se calcula, de dónde sale y quién lo gobierna.
Valor neto facturado a nivel de ítem de factura.
SUM(net_value)
Excluye tipos de factura de anulación.
Qué proporción de lo pedido se entregó realmente.
SUM(delivered_qty) / SUM(ordered_qty)
Pedidos confirmados que aún no se entregan.
SUM(confirmed_open_value)
Cuánto vale, en promedio, cada documento de venta.
NET_REVENUE / COUNT(DISTINCT billing_document)
Días promedio entre crear el pedido y facturarlo.
AVG(billing_date − order_date)
Clientes con al menos una factura en el periodo.
COUNT(DISTINCT customer_id)
Si cada herramienta calculara sus KPIs, tarde o temprano divergen. Por eso la fórmula se define una vez y las herramientas solo la leen.
Se ajusta en un solo lugar: la vista views.py / kpi_*.
Un solo cambio en la capa semántica de Athena.
QuickSight y Power BI muestran el nuevo valor. Sin tocar cada reporte.
Regla de paridad: SUM(net_value) en la vista = misma cifra en QuickSight = misma cifra en Power BI.
Verificado automáticamente: si difieren, la prueba falla.
No toda la lógica vive en el mismo sitio. Cada tipo de regla entra donde corresponde.
Cada vista publicada tiene esquema versionado, dueño responsable y SLA de frescura. Es un compromiso explícito, no una tabla suelta.
Una vez se trae la historia completa. Después, solo lo que cambia.
Traemos toda la historia de SAP, dividida en bloques manejables para no saturar el sistema.
Cada pocas horas traemos únicamente los documentos nuevos o modificados. Rápido y barato.
Seguimos Ventas Netas desde el campo crudo de SAP hasta el tablero. Sin magia.
NETWR en VBRPEl valor neto de cada ítem de factura, tal como SAP lo registra.
Tipado a decimal, moneda PEN reconocida, ligado a su factura. Sin duplicados (Iceberg MERGE).
fact_billingModelo estrella: el ítem de factura enlazado a cliente, material, fecha y organización de ventas.
kpi_revenue_summaryNet Revenue = SUM(net_value) — definida una sola vez, en el catálogo.
La misma cifra en QuickSight y Power BI. Trazable hasta el campo de SAP que la originó.
La forma en que organizamos hechos y dimensiones en el oro. Aquí el porqué de la decisión.
Pasa el cursor (o toca) un hecho para ver con qué dimensiones se relaciona.
Grano: cada fila es un ítem de documento (ítem de factura, de pedido, de entrega). El nivel de detalle más fino, para poder agregar como se quiera.
Hechos al centro, dimensiones directamente alrededor. Plano y simple.
Dimensiones normalizadas en cadenas de tablas. Ahorra almacenamiento.
El sustento: el copo de nieve normaliza para ahorrar almacenamiento; la estrella prioriza velocidad de consulta y claridad. Con S3 el almacenamiento cuesta poco, así que optimizamos lo que de verdad importa: que los tableros respondan rápido y que el negocio entienda el modelo. El matiz: usamos SCD Tipo 2 en cliente y material para conservar la historia de cambios, sin renunciar a la simpleza de la estrella.
Despliega la capa que te interese.
Formato: JSONL comprimido (gzip) en S3. Qué guardamos: el dato original sin modificar, con metadatos del lote (entidad, rango, timestamp, job_id).
Por qué: tener el original intacto permite reprocesar sin volver a molestar a SAP. Es nuestra red de seguridad y la base de la auditoría.
Qué pasa: tipos de dato correctos (fechas SAP YYYYMMDD → fecha real, textos, decimales), encoding y nombres de campo consistentes.
Resultado: el dato deja de ser un volcado crudo y se vuelve legible por máquina, listo para relacionarse.
Tecnología: tablas Apache Iceberg. Cada carga hace MERGE por clave de negocio (documento + ítem), así reejecutar nunca duplica.
Qué se gana: pedidos, entregas y facturas quedan enlazados vía el flujo de documentos (VBFA). Los registros que fallan validación van a cuarentena.
Modelo estrella: hechos (fact_billing, fact_sales_order, fact_delivery) rodeados de dimensiones (cliente, material, fecha, organización).
Enriquecimiento: códigos SAP resueltos a nombres (KUNNR → "SAN FERNANDO S.A."). Historial de cambios preservado (SCD tipo 2) en cliente y material.
El dato está protegido y cada cifra es auditable.
Roles IAM por servicio y entorno. Sin credenciales estáticas, mínimo privilegio.
Datos cifrados en reposo con llaves propias (CMK por capa) y en tránsito por TLS.
Las credenciales de SAP/HANA nunca están en el código. Se leen protegidas y rotables.
Cada usuario ve solo su organización de ventas (sales_org). Definido una vez, reflejado en ambos BI.
Reconciliación origen = cargado en cada corrida. Se sabe de dónde viene cada dato.
El dato que falla calidad se aparta y se audita. Solo lo confiable llega al oro.
Por qué esta plataforma
Un indicador, una definición. Igual en QuickSight y Power BI.
Trazabilidad de SAP al KPI. Todo auditado, nada inventado.
Más de 8 millones de filas procesadas de forma idempotente.
Arquitectura abierta en AWS. Cambias de herramienta BI cuando quieras.
De SAP a la decisión, con datos en los que puedes confiar.
Montana BI · SAP S/4HANA SD sobre AWS