Al integrar mi ERP y CRM (y otras herramientas), ¿cómo

Respuesta

Define un único dueño por cada dato o incluso por cada campo y fuerza que todos los demás sistemas solo lo consuman o lo propongan, pero no lo “manden”. En la práctica, el ERP suele ser el dueño de lo fiscal y transaccional, el CRM de lo comercial y relacional, y el resto se reparte por proceso. Lo importante no es escoger “el sistema más importante”, sino el sistema más cercano al control y a la validación de ese dato. A partir de ahí, diseña la sincronización para que no haya ediciones simultáneas sin reglas, que es donde nacen las incoherencias.

Objetivo: definir propiedad del dato y reducir incoherencias

El problema típico no es que falte una integración, sino que sobran “verdades” compitiendo. Un vendedor cambia el nombre del cliente en el CRM, finanzas lo ajusta en el ERP, marketing lo corrige en una herramienta de campañas, y de repente el mismo cliente existe con tres variantes. Definir Source of Truth no es un debate filosófico, es una regla operativa: quién tiene permiso de escribir y quién solo puede leer, por cada dato relevante.

Un matiz útil para equipos ejecutivos es separar “system of record” y “source of truth”. El system of record es donde queda el registro oficial con auditoría, por ejemplo una factura en el ERP. El source of truth puede ser por campo: el email del contacto puede ser más confiable en el CRM, mientras que el NIF y la dirección fiscal deben ser confiables en el ERP. Este enfoque por atributo reduce fricción y evita el falso dilema de elegir un único sistema maestro para todo, algo que suele romperse en cuanto hay excepciones.

Paso 1: inventariar entidades, atributos y flujos de negocio

Antes de asignar dueños, necesitas un mapa. No un diagrama bonito para una presentación, sino un inventario que responda: qué datos existen, quién los crea, quién los usa y qué ocurre cuando cambian. En integraciones ERP y CRM, los flujos que más mandan son lead to cash y procure to pay, porque cruzan comercial, operaciones y finanzas.

Te recomiendo capturar tres cosas por entidad: atributos críticos, eventos de cambio y sistemas productores y consumidores. Por ejemplo, para “cliente” no basta con “nombre y dirección”, porque el cliente fiscal y el cliente comercial suelen divergir. Para “producto”, un SKU tiene atributos operativos, pero también atributos de catálogo, marketing o ecommerce.

Si quieres un arranque práctico, empieza por estas entidades y eventos:

Cliente y contacto: alta, cambio de datos fiscales, cambio de email o teléfono, baja o inactivación.
Producto o SKU: alta, cambio de descripción, cambio de unidad, baja.
Precio: alta de tarifa, cambio de tarifa, descuento excepcional, vigencia.
Stock: entrada, salida, reserva, ajuste por inventario.
Pedido y factura: creación, confirmación, contabilización, cancelación, abono.

Tip práctico 1: no intentes inventariar “todo el ERP”. Toma el top 20 de campos que más rompen operación y reporting, y que disparan tickets internos. Con eso normalmente ya eliminas la mayor parte del dolor.

Paso 2: criterios para asignar el Source of Truth por dato o por campo

Asignar SoT funciona mejor como una decisión ponderada. Los criterios que más he visto funcionar en integraciones reales son:

Autoridad legal o fiscal. Si hay impuestos, cumplimiento o auditoría, el ERP suele ganar.
Cercanía al proceso donde nace el dato. El dato debe “nacer” donde se valida y se aprueba.
Calidad de validaciones. Si un sistema obliga a reglas, catálogos y aprobaciones, es mejor candidato.
Necesidad de trazabilidad. Si necesitas saber quién cambió qué y cuándo, prioriza el sistema con mejor bitácora.
Latencia tolerable. Si el negocio necesita el dato en segundos, diseña para eventos; si tolera horas, un batch puede ser suficiente.
Volumen y desempeño. Stock y precios masivos exigen integraciones cuidadas.
Propiedad organizacional. Quien responde por el dato debe poder controlarlo sin pedir favores.

Regla de oro que reduce incendios: evita bidireccionalidad total. Si dos sistemas pueden escribir el mismo campo sin un árbitro, tarde o temprano uno “pisará” al otro. Es como tener dos volantes en el mismo coche: divertido en una película, caro en una empresa.

Matriz recomendada SoT por dominio (cliente, producto, precio, stock, facturas)

Esto no es universal, pero sí una base sólida para la mayoría de compañías B2B, distribución y servicios con facturación desde ERP.

Cliente.

El ERP suele ser SoT de identidad fiscal, condiciones de pago, límites de crédito, cuentas contables y dirección fiscal. El CRM suele ser SoT de datos comerciales como etapa, owner, notas, actividad, contactos, preferencias, y a veces dirección de envío si la gestiona ventas. Si existe ecommerce o soporte, esos sistemas pueden proponer datos, pero normalmente no deberían ser los dueños.

Producto.

El ERP suele ser SoT del SKU, unidad de medida, coste, reglas de inventario, y si aplica, estructura de producto. Un PIM o ecommerce suele ser SoT de descripciones largas, imágenes y atributos de catálogo. El CRM rara vez debe ser SoT de producto, salvo para catálogos ligeros o bundles puramente comerciales.

Precio.

El ERP suele ser SoT de tarifas base, impuestos, vigencias y condiciones estándar. Un CPQ o el propio CRM puede ser SoT de precios negociados y descuentos por oportunidad, pero con una condición: cuando se confirma el pedido o la orden de venta, ese precio debe publicarse al ERP como el precio aplicado, con su motivo y su vigencia.

Stock.

ERP o WMS deben ser SoT de stock físico, stock disponible y reservas. El CRM debería consumir disponibilidad para prometer fechas, pero no editar stock. Si prometes entregas desde el CRM sin una fuente única de stock, acabarás vendiendo humo, que es el producto más barato y el más caro a la vez.

Facturas.

El ERP debe ser SoT de factura, numeración fiscal, impuestos, contabilización, abonos y estado de cobro. El CRM debe consumir el estado para que ventas sepa si el cliente está al día, pero no debe generar “facturas paralelas” salvo que sean proformas claramente separadas.

Patrones de sincronización: unidireccional, bidireccional controlado y “golden record”

Hay tres patrones sanos. Elegir el patrón correcto es más importante que la herramienta concreta.

Unidireccional maestro a suscriptores.

Un sistema escribe y los demás leen. Es el patrón más robusto para stock, facturas y datos fiscales. Minimiza conflictos y simplifica soporte.

Bidireccional controlado por campos.

Se permite que ambos sistemas aporten datos, pero cada campo tiene dueño. Por ejemplo, el CRM puede escribir teléfono y email comercial, mientras el ERP escribe NIF, razón social fiscal y condiciones de pago. Requiere reglas de precedencia claras y, a veces, ventanas de edición.

Golden record.

Creas un “registro dorado” consolidado, típico de MDM, donde se aplican reglas de supervivencia y deduplicación. Es útil cuando hay muchas fuentes y calidad dispar, o cuando el mismo cliente entra por múltiples canales. También es donde conviene mirar cuando tu problema real es “datos maestros inconsistentes”, un tema muy común en integraciones ERP y CRM.

Identidad del dato: IDs, claves externas y deduplicación

La integración se rompe más por identidad que por APIs. Si no sabes que “ACME S.L.” y “Acme SL” son la misma cuenta, tu reporting y tu facturación se separan como una mala pareja.

Recomendación práctica:

Define un ID canónico interno para cada entidad maestra, por ejemplo un UUID.
Mantén external IDs por sistema, por ejemplo el ID del ERP, el ID del CRM y el ID del ecommerce.
Gestiona una tabla de correspondencias. Puede vivir en tu capa de integración o en un repositorio dedicado, pero debe ser auditable.
Establece reglas de matching. Para empresa, NIF o VAT más país y razón social es un buen inicio. Para contactos, email y dominio ayudan. Para producto, SKU más compañía suele ser el mínimo.

Tip práctico 2: antes de conectar flujos críticos, haz una “limpieza mínima viable” de duplicados en cliente y producto. No hace falta perfección, pero sí eliminar los duplicados que ya sabes que existen y que se usan a diario.

Gobierno de cambios: precedencia, ventanas de edición y resolución de conflictos

Definir SoT sin gobierno es como poner señales de tráfico sin multas. Necesitas reglas operativas para cuando dos cambios compiten.

Tres mecanismos sencillos que funcionan:

Precedencia por campo. Documento vivo que diga quién manda en cada atributo.
Ventanas de edición. Por ejemplo, datos fiscales solo se editan en ERP y solo en horario laboral con aprobación, mientras que datos comerciales se editan en CRM en cualquier momento.
Resolución de conflictos. Para campos no críticos, “última escritura gana” puede ser aceptable. Para campos críticos, crea una cola de revisión humana cuando haya conflicto, y registra auditoría.

Error común: activar sincronización bidireccional para “cliente completo” porque parece más simple. Lo que pasa en realidad es que creas bucles de actualización, duplicados y cambios que se pisan, y el equipo acaba desactivando integraciones por urgencia. En su lugar, define bidireccionalidad solo para campos concretos y deja el resto en unidireccional desde el dueño.

Consistencia vs latencia: diseñar con eventos y estados

El negocio suele pedir dos cosas a la vez: consistencia perfecta y tiempo real. En integraciones reales, siempre hay una compensación. Lo correcto es declarar latencia tolerable por dato y diseñar con estados intermedios.

Por ejemplo, un cliente creado en CRM puede estar en estado “pendiente de alta en ERP”. Mientras tanto, el CRM permite avanzar una oportunidad, pero no permite facturar. Cuando el ERP confirma el alta, se actualiza el estado. Este enfoque reduce llamadas de “por qué no aparece” y evita que la gente haga atajos manuales.

Si tienes capacidad, prioriza eventos o notificaciones de cambio, como webhooks o CDC, para stock y estados de pedido, y deja procesos menos sensibles en lotes. También diseña reintentos idempotentes y una cola de errores para no perder datos cuando un sistema cae.

Aquí va la tabla determinística de controles operativos que conviene configurar en cualquier integración.

Set: Identificar eventos de cambio de datos. Define qué cambios disparan sincronización y cuáles no.

Set: Establecer latencia tolerable para cada integración. Alinea expectativas y evita falsas urgencias.

Set: Manejar errores de integración. Reintentos, alertas y una cola de fallos evitan pérdidas silenciosas.

Set: Mapear campos de forma explícita. Sin mapeo documentado, el dato se degrada sin que nadie lo note.

Set: Evitar sincronización bidireccional total (anti patrón). Bidireccionalidad solo cuando esté acotada por campo.

Decisiones específicas por tipo de dato (cliente, producto, precio, stock, facturas)

Cliente.

Decide si la “cuenta” del CRM corresponde a “cliente” en ERP o si hay etapas intermedias, como prospecto, cliente aprobado, cliente con crédito. En muchas compañías, el CRM crea el prospecto y el ERP crea el cliente fiscal definitivo tras validación. Sin esa distinción, terminas con facturación bloqueada o con clientes sin control de riesgo.

Producto.

Define si el alta de SKU nace en ERP o en un sistema de catálogo. Si vendes en múltiples canales, separar atributos operativos y atributos de catálogo suele ser lo más sano. El ERP manda en lo que afecta a inventario y coste. El catálogo manda en lo que afecta a conversión.

Precio.

Evita que el CRM “invente” precios sin referencia. Lo ideal es que el CRM consuma listas base desde ERP y aplique descuentos dentro de límites aprobados, con registro del motivo. Cuando la oportunidad se convierte en pedido, el ERP debe recibir el precio aplicado y congelarlo para que contabilidad no vea números que cambian después.

Stock.

Aclara qué significa “disponible”. No es lo mismo stock físico que ATP, available to promise, que es stock descontando reservas. Si el CRM muestra stock, especifica si muestra físico, disponible o una estimación por fecha. La precisión depende de tu operación, pero la definición debe ser única.

Facturas.

Si el CRM necesita “ver la factura”, integra el estado y el PDF, pero no dejes que el equipo comercial edite datos de factura desde CRM. Si necesitan corregir algo, el CRM puede abrir un caso o una solicitud, y el ERP ejecuta el cambio con trazabilidad.

Arquitectura mínima viable (sin sobre ingeniería)

Para la mayoría de empresas, la arquitectura mínima viable tiene cinco piezas:

Una capa de integración. Puede ser iPaaS o integraciones directas, pero con monitorización y reintentos.
Un repositorio de mapeos y reglas. Aunque sea un documento vivo al principio, debe existir y tener dueño.
Gestión de identidad. External IDs y tabla de correspondencias.
Observabilidad. Alertas cuando hay fallos, retrasos o colas creciendo.
Entorno de pruebas y datos de prueba. Sin esto, cada cambio será una ruleta.

Solo añade un MDM formal o un bus de eventos completo cuando tengas señales claras: demasiadas fuentes de cliente y producto, deduplicación recurrente, o necesidad de gobernanza centralizada. Si no, empezarás construyendo un aeropuerto para despegar una avioneta.

Si tienes que decidir por dónde empezar, mi recomendación es priorizar dos frentes: primero, cliente fiscal y facturas en unidireccional desde ERP; segundo, sincronización controlada de cliente comercial y contactos desde CRM, con IDs estables y reglas de deduplicación. Una vez eso está firme, precios y stock se vuelven mucho más predecibles, y tu operación deja de depender de “pregúntale a Juan que él sabe cuál es el bueno”.

Control	Dónde vive	Qué configurar	Qué se rompe si está mal
Set: Identificar eventos de cambio de datos	Diagramas de flujo de procesos	Triggers o APIs para notificar cambios entre sistemas	Sistemas desactualizados. operaciones basadas en información vieja
Set: Establecer latencia tolerable para cada integración	Acuerdos de Nivel de Servicio (SLA)	Frecuencia de sincronización (tiempo real, diario, semanal)	Retrasos operativos. clientes insatisfechos por información no disponible
Set: Manejar errores de integración	Plataforma de integración (iPaaS)	Alertas, reintentos automáticos, colas de mensajes	Pérdida de datos. interrupción de procesos de negocio críticos
Set: Mapear campos de forma explícita	Documentación de mapeo de datos	Transformaciones y validaciones de datos entre sistemas	Datos ilegibles o incorrectos en el sistema destino
Set: Evitar sincronización bidireccional total (anti-patrón)	Política de integración de datos	Flujos unidireccionales o bidireccionalidad controlada por campo	Bucles infinitos de actualización. corrupción masiva de datos
Set: Definir Sistema de Registro (SoR) para cada dato maestro	Documento de arquitectura de datos	Reglas de origen de datos por entidad (ej. Cliente, Producto)	Datos duplicados, inconsistentes. reportes erróneos

Fuentes

Última actualización: 2026-05-22 | Calypso

Al integrar mi ERP y CRM (y otras herramientas), ¿cómo defino el “source of truth” por dato (cliente, producto, precio, stock, facturas) y evito incoherencias?

Respuesta

Fuentes

Etiquetas