Hace más de cinco mil años, alguien apoyó un estilete sobre una pequeña superficie de arcilla en Mesopotamia. No intentaba escribir un poema ni dejar testimonio de una batalla. Estaba registrando grano.
Una tablilla administrativa conservada por el Metropolitan Museum of Art y datada aproximadamente entre 3100 y 2900 a. C. contiene símbolos numéricos relacionados probablemente con entregas de cereal. Los primeros sistemas de escritura se utilizaron en gran medida para conservar información económica. Aquella tablilla era una tecnología empresarial.
También guarda una advertencia moderna. Al haberse perdido parte del contexto de sus creadores, hoy no podemos interpretar todos sus signos con certeza. Conservamos el dato, pero una parte de su significado ha desaparecido.
Cinco milenios después, muchas empresas poseen millones de registros en SAP, almacenes de datos y aplicaciones cloud. Pueden conservar una operación hasta el último decimal y, aun así, carecer de una interpretación común de qué significa cada cifra.
La empresa necesita conservar el significado
Dos departamentos pueden calcular los ingresos de forma correcta y obtener resultados distintos porque uno utiliza facturación y otro reconocimiento contable. Una IA puede recuperar ambas cifras en milisegundos. Eso no significa que sepa cuál debe emplear.
El desafío es suministrar relaciones, definiciones, permisos, procedencia y contexto empresarial. Es decir, conseguir que el sistema no solo lea los signos de la tablilla, sino que comprenda la administración que los creó.
Qué es SAP Business Data Cloud
SAP presenta Business Data Cloud como una solución conectada que relaciona datos SAP y de terceros mediante una arquitectura de business data fabric. Reúne capacidades de integración, modelado, analítica, planificación, productos de datos y conocimiento empresarial.
No es simplemente una base de datos nueva ni una obligación de copiar todo a un único repositorio. Su propuesta consiste en crear una base gobernada sobre la que puedan trabajar analítica e IA.
Cuatro niveles para entender la arquitectura
Los sistemas conservan la operación
SAP S/4HANA y las aplicaciones especializadas siguen generando pedidos, asientos, contratos e incidencias. El acceso puede utilizar federación, replicación, eventos o intercambio sin copias, según requisitos de latencia, coste y gobierno.
Los productos de datos convierten tablas en activos
Un producto de datos expone información acompañada de metadatos, responsables, reglas de acceso y mecanismos de consumo. El dato deja de ser un residuo técnico y pasa a tener consumidores y ciclo de vida.
El conocimiento preserva relaciones
Un proveedor suministra un material; el material participa en una orden; la orden afecta a una planta; la planta pertenece a una sociedad. Grafos y modelos semánticos permiten representar esas relaciones para que una aplicación interprete mejor una pregunta.
La IA convierte contexto en acción
Un agente de compras podría detectar una anomalía, relacionarla con fiabilidad del proveedor, comprobar inventario y proponer una alternativa. Para hacerlo con seguridad necesita políticas y consecuencias, no solo acceso a tablas.
Zero-copy no significa zero-work
SAP Business Data Cloud Connect plantea compartir datos con plataformas como Databricks, Snowflake, Microsoft Fabric, Google BigQuery o Amazon Athena reduciendo copias innecesarias. Eso puede disminuir latencia e inconsistencias, pero no elimina identidad, calidad, semántica, linaje, retención ni responsabilidad.
Una calzada romana evitaba abrir un camino nuevo para cada caravana. Seguía necesitando puentes, mantenimiento y autoridades. Una infraestructura compartida reduce fricción; no sustituye el gobierno.
El contrato de un producto de datos
Un producto de datos útil debe explicar qué representa, quién responde por él, con qué frecuencia se actualiza y qué nivel de calidad puede esperar el consumidor. También necesita condiciones de acceso y una política frente a cambios incompatibles.
Sin ese contrato, el catálogo se convierte en un almacén de nombres atractivos. Los consumidores vuelven a preguntar al creador por correo, crean su propia copia y la promesa de reutilización desaparece.
Semántica no significa uniformidad absoluta
Las empresas pueden necesitar varias vistas legítimas de una realidad. El margen para Dirección Comercial puede responder a una decisión distinta del margen contable. Gobernar no siempre significa imponer una única cifra, sino declarar definición, propósito y relación entre ambas.
La IA debe recibir esa distinción. Una pregunta ambigua puede requerir que el agente pida contexto en lugar de elegir silenciosamente la métrica más accesible.
Coste, latencia y soberanía
La arquitectura de datos es también una arquitectura económica. Replicar grandes volúmenes, ejecutar consultas federadas o mantener modelos en tiempo real produce costes diferentes. La decisión debe atender a frecuencia de uso, criticidad y necesidad de aislamiento.
Región, residencia, contratos y datos personales pueden limitar dónde se procesa la información. «Conectado» no significa que todo deba estar disponible para todos los modelos o usuarios.
El producto mínimo no es toda la plataforma
Una empresa puede comenzar seleccionando un dominio, una decisión y un pequeño conjunto de productos de datos. El objetivo del piloto es comprobar si las definiciones son comprensibles, si el acceso funciona y si un consumidor obtiene valor. Incorporar decenas de fuentes antes de validar el contrato multiplica trabajo sin demostrar utilidad.
El primer éxito debería dejar activos reutilizables: glosario, propietarios, controles, patrones de acceso y métricas. Así el segundo caso empieza desde un peldaño más alto en lugar de repetir el descubrimiento.
La confianza como propiedad observable
Decir que un dato está gobernado no basta. Los usuarios necesitan ver frescura, procedencia, incidencias abiertas y responsable. La confianza aumenta cuando el sistema reconoce sus límites y permite investigar una discrepancia.
Cómo comenzar sin construir un monumento vacío
- Elegir una decisión concreta: tesorería, inventario, proveedores o rentabilidad.
- Documentar las definiciones que compiten dentro de la organización.
- Designar propietarios funcionales y técnicos del dominio.
- Crear un producto de datos piloto con consumidores identificados.
- Validar analítica antes de conceder autonomía a un agente.
- Medir tiempo de decisión, conciliaciones, errores y confianza.
Los nuevos escribas
Los escribas de Uruk resolvieron un problema de escala: convirtieron intercambios efímeros en registros duraderos. Nosotros afrontamos el desafío inverso. Hemos construido sistemas capaces de registrar casi todo, pero debemos impedir que el significado se pierda entre tablas, copias y modelos.
Business Data Cloud no será una piedra de Rosetta automática. Ninguna plataforma puede reconciliar departamentos que no comparten definiciones o responsabilidades. Puede, sin embargo, proporcionar una arquitectura donde esos acuerdos sean visibles, reutilizables y gobernables.
La próxima frontera de la IA empresarial no consiste únicamente en construir modelos más poderosos. Consiste en enseñarles qué significa realmente una empresa.
