Definición / Qué es
Single Source of Truth (SSOT), en español “fuente única de la verdad”, es un principio de arquitectura de información que establece que cada dato relevante de la organización debe tener un único origen autoritativo, y cualquier otro sistema que lo necesite debe leerlo o recibirlo replicado, pero nunca modificarlo en paralelo. Es la versión aplicada al dato de un principio universal de ingeniería: una sola persona o sistema responsable, una sola fuente de cambio, una sola verdad.
El concepto se generaliza con la consolidación de los ERP en los años 90 y se hace explícito en la literatura de gobernanza de datos a partir de los 2000. Está estrechamente ligado a MDM —la disciplina que hace operativo el principio— pero no son lo mismo: SSOT es el “qué” (un único origen autoritativo), MDM es el “cómo” (procesos, roles y herramientas para garantizarlo).
Hay un matiz importante. El SSOT no significa que un dato exista físicamente en un único sitio: en una arquitectura moderna casi todo está replicado por motivos de rendimiento, resiliencia y analítica. Significa que existe un sistema autoritativo —el único que puede modificarlo— y los demás reciben copias derivadas. Si la copia y el original divergen, el original gana. Esta sutileza es clave para entender por qué dos sistemas pueden tener el mismo dato sin violar el principio.
Por qué importa
El primer motivo es decisión. Sin SSOT, la pregunta “¿cuánto facturamos el mes pasado?” tiene varias respuestas según el sistema consultado: BC, el CRM, el portal de cliente, el cuadro de mando, el Excel del director financiero. Cada uno corta el dato en una fecha distinta, aplica reglas distintas y descuenta cosas distintas. El comité directivo se gasta la reunión discutiendo qué número es bueno en lugar de qué decisión tomar.
El segundo es operativo. Si el stock vive a la vez en BC y en el e-commerce, y los dos se editan, en cuanto haya retraso de sincronización se vende stock que no existe. Si el cliente vive en BC y en el CRM y los dos se editan, hay teléfonos contradictorios y direcciones de envío equivocadas. Cada “doble verdad” genera incidencias que se traducen en horas de mostrador, devoluciones y churn de cliente.
El tercero es legal y regulatorio. RGPD obliga a saber qué datos personales se tienen, dónde, y a borrarlos cuando el titular lo pide. Sin SSOT no se sabe dónde están: hay copias replicadas en sitios olvidados que sobreviven al borrado nominal. Lo mismo con Verifactu/SIF: el registro de facturación obligatorio exige que los datos del emisor y del cliente sean los mismos del ERP; cualquier divergencia es inspeccionable.
El cuarto es arquitectónico: si BC es la verdad de cliente, todas las apps apuntan a BC vía API REST o reciben push desde BC. El número de integraciones a mantener cae drásticamente.
Aplicación en Business Central
En una arquitectura típica de PYME industrial o de servicios sobre Business Central, el reparto de “verdades” suele ser:
- BC es SSOT de: pedidos de venta y de compra, facturación emitida y recibida, contabilidad, stock físico, listas de materiales, condiciones de pago, datos fiscales del cliente, datos del proveedor. Es lo que el ERP hace por definición.
- CRM (Dynamics 365 Sales) es SSOT de: oportunidades, actividades comerciales, contactos antes del primer pedido, gestión de propuestas. Una vez la oportunidad se convierte en pedido, la verdad transaccional pasa a BC.
- GMAO (con la extensión dvgmao) es SSOT de: equipos, partes de mantenimiento, planes preventivos, históricos de averías. BC consume estos datos para el reporting de coste de mantenimiento.
- MES o módulo de producción (con dvproduction) es SSOT de: partes de fabricación en tiempo real, consumos reales, mermas. BC recibe los movimientos consolidados.
- e-commerce suele ser SSOT de cuenta del cliente final y comportamiento web, pero no del catálogo (viene de BC) ni del stock (viene de BC) ni del pedido (se sube a BC).
- RRHH es SSOT de empleados, no BC.
- Dataverse / Fabric no son SSOT por sí mismos: son hubs de replicación que reciben copias para analítica y para integración Power Platform.
Las decisiones de “quién es SSOT de qué” hay que tomarlas explícitamente al diseñar la arquitectura, escribirlas y revisarlas anualmente. Es un trabajo de gobernanza, no de desarrollo.
Errores frecuentes
- No declararlo explícitamente. “Damos por supuesto que el cliente está en BC” sin escribirlo lleva a que el comercial edite en el CRM y nadie sepa qué versión gana.
- Permitir escritura paralela. Dos sistemas que escriben en el mismo dato sin reglas de prevalencia generan el “ping-pong de actualizaciones”: el último que sincroniza gana, los demás pierden cambios silenciosamente.
- Confundir SSOT con monolitismo. SSOT no exige meter todo en BC. Exige que cada dato tenga un dueño claro; ese dueño puede ser otro sistema mejor especializado.
- Pensar que el data warehouse es el SSOT. No lo es: es una copia analítica. La verdad sigue viviendo en los operativos. Si un dato del warehouse no cuadra con BC, BC manda.
- No revisar el mapa cuando cambia el stack. Cada aplicación nueva (TPV, marketplace, app móvil) obliga a redecidir qué es SSOT de qué.
- Tolerar Excel paralelos. Una copia departamental “para sus cosas” crea una verdad alternativa que tarde o temprano contradice al ERP.