E-commerce y ERP

Qué significa realmente "una sola fuente de verdad" para los datos de producto

Ingeniería de DigSolutions··3 min de lectura
Bastidor de servidores con equipo de redes en una sala de datos oscura

Puntos clave

  • "Una sola fuente de verdad" es una decisión de arquitectura, no la descripción de tener una hoja de cálculo o panel compartido.
  • El mapeo de SKU entre plataformas es el trabajo poco vistoso que hace o deshace todo el sistema.
  • Las reglas de resolución de conflictos, no solo el almacenamiento de datos, son las que determinan qué valor gana cuando dos canales no coinciden.
  • Una fuente de verdad tiene que ser dueña de las escrituras, no solo agregar lecturas, o es una capa de reportes con un título más grande.

"Una sola fuente de verdad" se usa como descripción de una intención, nos gustaría que nuestros datos fueran consistentes, cuando en realidad es una decisión de arquitectura con requisitos específicos. Un panel que extrae números de tres plataformas y los muestra juntos no es una fuente de verdad. Es una capa de reportes, y hereda cualquier inconsistencia que ya exista en los sistemas subyacentes.

El primer requisito real es el mapeo de SKU, y es la parte menos vistosa de todo el proyecto. Amazon, Shopify y WooCommerce le permiten cada uno a un vendedor estructurar los identificadores de producto de forma distinta, y un producto que genuinamente es el mismo artículo puede tener tres SKU distintos, tres títulos distintos y tres estructuras de variantes distintas entre plataformas. Antes de que cualquier lógica de sincronización pueda funcionar, algo tiene que mapear de forma fiable que "estas tres fichas son el mismo producto", incluso cuando un proveedor cambia el formato de un SKU o cambian las propias reglas de identificación de una plataforma.

El segundo requisito es decidir qué sistema es dueño de qué campo, no solo dónde viven los datos, sino qué valor de qué plataforma gana cuando dos no coinciden. El precio podría gestionarse centralmente y distribuirse igual en todas partes; la descripción del producto podría variar por canal por razones de SEO; el conteo de stock tiene que ser de propiedad central o toda la premisa se desmorona. Sin reglas explícitas de propiedad por campo, "sincronizar" simplemente significa "gana el último sistema que escribió", lo que produce exactamente el tipo de deriva de datos silenciosa que se supone que una fuente de verdad debe evitar.

El tercer requisito es la resolución de conflictos para los casos que las reglas de propiedad no cubren de forma clara: un producto editado directamente en Shopify por alguien que no sabía que se gestionaba centralmente, o una edición de cumplimiento específica de Amazon que tiene que sobrevivir a la siguiente sincronización en lugar de sobrescribirse en silencio. Un sistema de fuente de verdad real necesita una respuesta explícita para esto, marcarlo para revisión, siempre deferir al sistema central, o alguna otra opción, elegida a propósito y no por el código que resultó ejecutarse último.

El cuarto requisito, y el que realmente separa una fuente de verdad de un panel elegante, es ser dueño de las escrituras, no solo de las lecturas. Un sistema que solo agrega datos de tres plataformas para reportes puede decirle que sus números no coinciden. Un sistema que es la fuente de verdad real es donde hace el cambio una vez y se propaga hacia afuera; las plataformas se convierten en canales sincronizados, no en copias editables de forma independiente.

Esto es lo que realmente describe la "gestión de información de producto" cuando los proveedores usan el término: un sistema central con identificadores mapeados, propiedad explícita de campos, resolución de conflictos definida, y autoridad de escritura hacia afuera a cada canal conectado. Sin las cuatro piezas, tiene una versión parcial que parece consistente hasta el día en que dos canales no coinciden y nadie puede decir con confianza cuál es el correcto.

Acertar en esto es sobre todo un problema de secuenciación, no técnico. Normalmente empezamos con los campos que causan más daño cuando se desalinean, stock y precio casi siempre son primero, logramos que esos sean de propiedad central y se sincronicen correctamente, y luego expandimos la propiedad de campos hacia afuera a medida que crece la confianza en el sistema. Intentar centralizar cada atributo de cada producto el primer día es cómo estos proyectos se estancan antes de entregar algo.

La recompensa, una vez que realmente está construido así, no es solo menos dolores de cabeza de conciliación. Es que añadir un nuevo canal de venta se convierte en un ejercicio de mapeo contra un sistema que ya sabe qué es verdad, en lugar de otra copia independiente de su catálogo que mantener sincronizada a mano.

¿Listo para hablar sobre su proyecto?

Cuéntenos qué está construyendo. Le responderemos en un día hábil con los siguientes pasos, sin rodeos comerciales.