¿Qué es un sistema de registro?

Un sistema de registro es el sistema autorizado para crear y mantener datos confiables de un dominio o proceso. Un CRM puede ser el sistema de registro de relaciones con clientes, un ERP de transacciones, un HCM de empleados, billing de facturas y un MES del estado de producción.

Que sea autorizado no significa que una sola aplicación contenga todos los hechos. El CRM puede ser owner de etapa e historial, billing de pagos y producto de entitlements.

También es distinto de una fuente única de verdad. Esa vista puede combinar varios sistemas. El sistema de registro conserva la creación, corrección y ciclo de vida oficial dentro de su dominio.

El primer requisito de un sistema de registro es un mapa acordado del ground truth. El negocio debe decidir qué entidades existen, qué sistema es owner de cada campo y cómo Objetos, Record Types, campos y relaciones expresan esa realidad.

En un CRM, People, Companies, Deals y Tickets pueden ser Objetos estándar. Un Record Type distingue Lead de Contact sin crear otra persona. Campos tipados hacen que email, teléfono, moneda, fecha y relaciones sean machine-readable.

Los agentes elevan el costo de la ambigüedad. Si dos sistemas reclaman ownership o la ontología es confusa, pueden propagar duplicados y estado incorrecto a velocidad de máquina.

Empezá por ground truth y ontología antes de elegir herramientas de sync. Nombrá los sustantivos, definí lifecycle, Objetos, Record Types, campos, cardinalidad y un owner para cada dato importante.

Después conectá fuentes. WhatsApp, Gmail y Outlook aportan identidad y actividad. Imports, APIs y aplicaciones operativas aportan registros. ETL, reverse ETL, warehouses y data lakes distribuyen o enriquecen, pero no ganan autoridad de escritura por defecto.

Cada sync mapea IDs a registros canónicos, valida tipos, aplica conflictos y registra provenance. Las correcciones vuelven al owner.

Un cliente informa a soporte que cambió la dirección de la empresa y pide corregir una factura. El CRM es owner del perfil, mientras billing es owner de facturas emitidas e impuestos.

El agente actualiza la dirección verificada en el CRM y luego llama al workflow aprobado de corrección en billing. No modifica una copia de la factura y asume que cambió el registro financiero.

Ambos sistemas emiten eventos con identificadores compartidos. Soporte ve la corrección en el timeline, pero billing sigue siendo autoritativo para la factura.

Mantené una matriz por campo con Objeto, Record Type, tipo, relación, source, writers, matching key, frescura, retención y conflictos.

Usá Objeto para un sustantivo con lifecycle, Record Type para una variante real, campo para un hecho, relación para una conexión y tabla o warehouse para apoyo analítico.

Probá identidad cross-source, conversión Lead a Contact, duplicados de email y teléfono, null versus false, timezones, deletes de relaciones, batches tardíos y correcciones humanas.