01What it isQué es
SC data architecture is the path data travels from ERP, WMS, TMS and partner feeds to the dashboards, models and APIs that use it; the lakehouse pattern keeps raw data in low-cost open storage and adds warehouse-grade structure, governance and performance on top.
La arquitectura de datos de SC es el recorrido que hacen los datos desde el ERP, el WMS, el TMS y las fuentes de socios hasta los tableros, modelos y APIs que los usan; el patrón lakehouse guarda los datos crudos en almacenamiento abierto de bajo costo y agrega encima la estructura, la gobernanza y el desempeño de un warehouse.
02Why it mattersPor qué importa
A control tower, a demand sensing model and a monthly S&OP deck all fail the same way when each pulls from a different copy of the truth. The lakehouse combines open data-lake storage with warehouse features such as transactions, schema enforcement and fast SQL, removing the need to maintain two separate systems (Armbrust, Ghodsi, Xin and Zaharia, 2021 — CIDR), and big-data analytics is expected to reshape how supply chains are designed and managed (Waller and Fawcett, 2013 — Journal of Business Logistics).
Una torre de control, un modelo de demand sensing y la presentación mensual de S&OP fallan igual cuando cada uno toma datos de una copia distinta de la verdad. El lakehouse combina el almacenamiento abierto del data lake con funciones de warehouse como transacciones, control de esquema y SQL rápido, y elimina la necesidad de mantener dos sistemas separados (Armbrust, Ghodsi, Xin y Zaharia, 2021 — CIDR); además, se espera que la analítica de big data transforme la forma en que se diseñan y gestionan las cadenas de suministro (Waller y Fawcett, 2013 — Journal of Business Logistics).
03How it is doneCómo se hace
1
Map sources and latency. List every source system and the data freshness each decision actually needs: minutes for allocation, a day for S&OP.
2
Land once, model centrally. Ingest raw data into one lakehouse and build governed, tested models and a semantic layer for shared KPIs like OTIF.
3
Run pipelines like operations. Monitor pipeline reliability and freshness with alerts and owners, and report them next to the operational KPIs they feed.
1
Mapea fuentes y latencias. Enlista cada sistema fuente y la frescura de datos que realmente necesita cada decisión: minutos para asignación, un día para S&OP.
2
Carga una vez, modela al centro. Ingiere los datos crudos en un solo lakehouse y construye modelos gobernados y probados, más una capa semántica para KPI compartidos como el OTIF.
3
Opera los pipelines como operación. Monitorea la confiabilidad y frescura de los pipelines con alertas y dueños, y repórtalas junto a los KPI operativos que alimentan.
04The concept in depthEl concepto a fondo
The SC data architecture stack: from transactional data to strategic intelligence›
Supply chain data architecture is the technical infrastructure that enables SC analytics — defining how data flows from operational systems (ERP, WMS, TMS) through integration layers to analytics platforms. The modern SC data architecture is a lakehouse: a data lake (raw, unprocessed data from all sources) combined with a data warehouse layer (transformed, modeled data optimized for analytics). Paired with streaming ingestion, this architecture can remove the day-long reporting lag of traditional nightly ETL cycles and support near-real-time SC analytics.
The 5 layers of a modern SC data architecture›
(1) Source systems: ERP (SAP, Oracle), WMS (Manhattan, Blue Yonder), TMS (Oracle TM, Blue Yonder TMS), supplier portals, and external data feeds (weather, market data). (2) Ingestion layer: real-time data pipelines (Kafka, Debezium) and batch ETL processes that extract data from source systems and load it into the lakehouse. (3) Storage layer: cloud object storage (S3, ADLS) for raw data + columnar format (Delta Lake, Iceberg) for structured analytical data. (4) Transformation layer: dbt, Spark, or ELT pipelines that model raw data into analytics-ready datasets. (5) Consumption layer: BI tools (Power BI, Tableau), ML platforms (Databricks, Vertex AI), and operational APIs that serve analytics consumers.
The data lakehouse vs. data warehouse: the SC analytics architecture decision›
Traditional data warehouses model and structure data before storage — a slow, expensive process that delays analytics by hours or days. Data lakehouses store raw data first and model it on demand — enabling real-time analytics on unprocessed data while maintaining the performance of structured queries. For SC operations where real-time inventory and order visibility is critical, the lakehouse architecture is now the reference design.
Intermediate vs. Advanced›
Intermediate: consumes SC data through analytics platforms; identifies data quality issues; defines analytics requirements for data engineering teams.
Advanced: designs the end-to-end SC data architecture; selects platform components; governs data quality and pipeline reliability; leads the migration from legacy reporting to modern analytics infrastructure.
Advanced: designs the end-to-end SC data architecture; selects platform components; governs data quality and pipeline reliability; leads the migration from legacy reporting to modern analytics infrastructure.
La pila de arquitectura de datos de SC: del dato transaccional a la inteligencia estratégica›
La arquitectura de datos de supply chain es la infraestructura técnica que habilita la analítica de SC: define cómo fluyen los datos desde los sistemas operativos (ERP, WMS, TMS), a través de las capas de integración, hasta las plataformas de analítica. La arquitectura de datos de SC moderna es un lakehouse: un data lake (datos crudos, sin procesar, de todas las fuentes) combinado con una capa de data warehouse (datos transformados y modelados, optimizados para analítica). Combinada con ingesta en streaming, esta arquitectura puede eliminar el rezago de un día en los reportes que imponen los ciclos ETL nocturnos tradicionales y soportar analítica de SC casi en tiempo real.
Las 5 capas de una arquitectura de datos de SC moderna›
(1) Sistemas fuente: ERP (SAP, Oracle), WMS (Manhattan, Blue Yonder), TMS (Oracle TM, Blue Yonder TMS), portales de proveedores y fuentes de datos externas (clima, datos de mercado). (2) Capa de ingesta: pipelines de datos en tiempo real (Kafka, Debezium) y procesos ETL por lotes que extraen los datos de los sistemas fuente y los cargan al lakehouse. (3) Capa de almacenamiento: almacenamiento de objetos en la nube (S3, ADLS) para datos crudos + formato columnar (Delta Lake, Iceberg) para datos analíticos estructurados. (4) Capa de transformación: dbt, Spark o pipelines ELT que modelan los datos crudos en conjuntos listos para analítica. (5) Capa de consumo: herramientas de BI (Power BI, Tableau), plataformas de ML (Databricks, Vertex AI) y APIs operativas que atienden a los consumidores de analítica.
Data lakehouse vs. data warehouse: la decisión de arquitectura para la analítica de SC›
Los data warehouses tradicionales modelan y estructuran los datos antes de almacenarlos, un proceso lento y costoso que retrasa la analítica horas o días. Los data lakehouses almacenan primero los datos crudos y los modelan según se necesite, lo que permite analítica en tiempo real sobre datos sin procesar sin perder el desempeño de las consultas estructuradas. En operaciones de SC donde la visibilidad en tiempo real de inventarios y pedidos es crítica, la arquitectura lakehouse es hoy el diseño de referencia.
Intermedio vs. Avanzado›
Intermedio: consume datos de SC a través de plataformas de analítica; identifica problemas de calidad de datos; define requerimientos de analítica para los equipos de ingeniería de datos.
Avanzado: diseña la arquitectura de datos de SC de extremo a extremo; selecciona los componentes de la plataforma; gobierna la calidad de datos y la confiabilidad de los pipelines; lidera la migración de los reportes heredados a una infraestructura de analítica moderna.
Avanzado: diseña la arquitectura de datos de SC de extremo a extremo; selecciona los componentes de la plataforma; gobierna la calidad de datos y la confiabilidad de los pipelines; lidera la migración de los reportes heredados a una infraestructura de analítica moderna.
05In practiceEn la práctica
Design the data architecture for the analytics use cases of 3 years from now — not just today's reporting requirements›
The most expensive data architecture mistake is under-building. A data architecture designed for today's 5 reports will be inadequate for tomorrow's real-time control tower, ML models, and external data integration. Design for the analytics maturity level you are targeting in 3 years, not the reports you are running today.
Implement a semantic layer (metric definitions) before exposing data to business users›
Raw data exposed directly to business users generates metric proliferation — 47 different definitions of "OTIF" calculated by 12 different analysts from the same source data. A semantic layer — a governed, centralized metric definition layer — ensures that every consumer calculates the same metric the same way.
Treat data pipeline reliability as an operational KPI — not an IT responsibility›
A supply chain that cannot trust its data is a supply chain that makes decisions on outdated information. Data pipeline reliability is an operational enabler, not a technical metric. SC leadership should monitor pipeline reliability with the same discipline as OTIF or inventory accuracy.
Diseñar la arquitectura de datos para los casos de uso analíticos de dentro de 3 años, no solo para los requerimientos de reporteo de hoy›
El error más caro en arquitectura de datos es quedarse corto. Una arquitectura diseñada para los 5 reportes de hoy será insuficiente para la torre de control en tiempo real, los modelos de ML y la integración de datos externos de mañana. Diseña para el nivel de madurez analítica que buscas alcanzar en 3 años, no para los reportes que corres hoy.
Implementar una capa semántica (definiciones de métricas) antes de exponer los datos a los usuarios de negocio›
Los datos crudos expuestos directamente a los usuarios de negocio provocan una proliferación de métricas: 47 definiciones distintas de “OTIF” calculadas por 12 analistas diferentes a partir de los mismos datos fuente. Una capa semántica —una capa centralizada y gobernada de definiciones de métricas— asegura que cada consumidor calcule la misma métrica de la misma forma.
Tratar la confiabilidad de los pipelines de datos como un KPI operativo, no como una responsabilidad de TI›
Una supply chain que no puede confiar en sus datos toma decisiones con información desactualizada. La confiabilidad de los pipelines de datos es un habilitador operativo, no una métrica técnica. La dirección de SC debe monitorearla con la misma disciplina que el OTIF o la exactitud de inventarios.
06Illustrative caseCaso ilustrativo
Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Illustrative case: SC data lakehouse implementation — FMCG company, 2023
| Before (legacy DW) | After (lakehouse) | Business impact |
|---|---|---|
| Daily batch ERP extract — 18-hour data lag for operational KPIs | Real-time ERP streaming via Debezium — <5 minute data lag | Control tower enabled for first time — operational decisions based on same-day data |
| 12 siloed reporting systems — no unified SC view | Single lakehouse — ERP + WMS + TMS + external data unified | Cross-system analytics enabled — OTIF root cause analysis reduced from 3 days to 2 hours |
Result: SC data lakehouse eliminated the 18-hour reporting lag, enabled real-time operational dashboards, and unified 12 previously siloed data sources into a single analytics platform. Analytics team headcount reduced by 2 FTE (freed from data pipeline maintenance) — redirected to analytics development.
Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Caso ilustrativo: implementación de un data lakehouse de SC — empresa de consumo masivo (FMCG), 2023
| Antes (DW heredado) | Después (lakehouse) | Impacto en el negocio |
|---|---|---|
| Extracción diaria por lotes del ERP: 18 horas de rezago en los datos de los KPI operativos | Streaming del ERP en tiempo real vía Debezium: <5 minutos de rezago | Torre de control habilitada por primera vez: decisiones operativas basadas en datos del mismo día |
| 12 sistemas de reporteo aislados: sin una vista unificada de SC | Un solo lakehouse: ERP + WMS + TMS + datos externos unificados | Analítica entre sistemas habilitada: el análisis de causa raíz del OTIF pasó de 3 días a 2 horas |
Resultado: El data lakehouse de SC eliminó el rezago de 18 horas en los reportes, habilitó tableros operativos en tiempo real y unificó 12 fuentes de datos antes aisladas en una sola plataforma de analítica. El equipo de analítica liberó 2 FTE del mantenimiento de pipelines, que se reasignaron al desarrollo de analítica.
07How it is measuredCómo se mide
Data Pipeline Reliability % (% of scheduled data loads completing on time)›
Data Pipeline Reliability % (% of scheduled data loads completing on time)
(Data pipeline runs completing on schedule / Total scheduled runs) × 100
Benchmark: >99% pipeline reliability in production SC analytics environments · <97% indicates infrastructure quality issues affecting analytics availability
⚠️ Data pipeline failures are invisible to SC operations teams until a dashboard goes blank or a KPI report is missing. Implement automated pipeline monitoring and alerting before deploying analytics to operational users.
Confiabilidad de pipelines de datos % (% de cargas de datos programadas que terminan a tiempo)›
Confiabilidad de pipelines de datos % (% de cargas de datos programadas que terminan a tiempo)
(Ejecuciones de pipelines terminadas en tiempo / Total de ejecuciones programadas) × 100
Referencia: >99% de confiabilidad de pipelines en entornos productivos de analítica de SC · <97% indica problemas de calidad de infraestructura que afectan la disponibilidad de la analítica
⚠️ Las fallas de los pipelines de datos son invisibles para los equipos de operaciones de SC hasta que un tablero se queda en blanco o falta un reporte de KPI. Implementa monitoreo y alertas automáticas de pipelines antes de liberar la analítica a los usuarios operativos.
08What you would useQué se usa
📌 SC Data Architecture Platforms
Databricks / Snowflake›
Module: Data Lakehouse Platform
Databricks and Snowflake are the reference platforms for enterprise SC data lakehouses — providing unified storage, transformation, and analytics capabilities for complex multi-source SC environments.
Databricks and Snowflake are the reference platforms for enterprise SC data lakehouses — providing unified storage, transformation, and analytics capabilities for complex multi-source SC environments.
dbt (data build tool)›
Module: Data Transformation & Semantic Layer
dbt is the reference tool for SC data transformation and semantic layer management — enabling version-controlled, tested metric definitions that ensure consistent KPI calculations across all analytics consumers.
dbt is the reference tool for SC data transformation and semantic layer management — enabling version-controlled, tested metric definitions that ensure consistent KPI calculations across all analytics consumers.
Apache Kafka / Debezium›
Module: Real-Time Data Ingestion
Apache Kafka and Debezium provide real-time data streaming from ERP, WMS, and TMS source systems — enabling sub-minute data latency in SC analytics platforms.
Apache Kafka and Debezium provide real-time data streaming from ERP, WMS, and TMS source systems — enabling sub-minute data latency in SC analytics platforms.
📌 Plataformas de arquitectura de datos de SC
Databricks / Snowflake›
Módulo: Plataforma de data lakehouse
Databricks y Snowflake son plataformas de referencia para data lakehouses empresariales de SC: ofrecen capacidades unificadas de almacenamiento, transformación y analítica para entornos de SC complejos con múltiples fuentes.
Databricks y Snowflake son plataformas de referencia para data lakehouses empresariales de SC: ofrecen capacidades unificadas de almacenamiento, transformación y analítica para entornos de SC complejos con múltiples fuentes.
dbt (data build tool)›
Módulo: Transformación de datos y capa semántica
dbt es la herramienta de referencia para la transformación de datos de SC y la gestión de la capa semántica: permite definiciones de métricas versionadas y probadas que aseguran cálculos de KPI consistentes para todos los consumidores de analítica.
dbt es la herramienta de referencia para la transformación de datos de SC y la gestión de la capa semántica: permite definiciones de métricas versionadas y probadas que aseguran cálculos de KPI consistentes para todos los consumidores de analítica.
Apache Kafka / Debezium›
Módulo: Ingesta de datos en tiempo real
Apache Kafka y Debezium permiten el streaming de datos en tiempo real desde los sistemas fuente ERP, WMS y TMS, con latencias de datos menores a un minuto en las plataformas de analítica de SC.
Apache Kafka y Debezium permiten el streaming de datos en tiempo real desde los sistemas fuente ERP, WMS y TMS, con latencias de datos menores a un minuto en las plataformas de analítica de SC.
The bottom lineEn corto
One governed copy of the data, fresh enough for the decision, beats twelve reporting systems that each tell a different story.
Una sola copia gobernada de los datos, lo bastante fresca para la decisión, vale más que doce sistemas de reporteo que cuentan historias distintas.
← PreviousAnteriorSC master data management: the foundation that determines whether the supply chain worksGestión de datos maestros de SC: la base que determina si las decisiones son confiablesNextSiguiente →Data quality management: ensuring SC decisions are made on trustworthy dataGestión de calidad de datos: asegurando que las decisiones de SC se tomen con información confiable
All D16 componentsTodos los componentes de D16D16 artifactsArtifacts de D16SCRA