Datos e Integraciones
Diseñar el contrato antes de conectar los sistemas.
Defino identidad, autoridad, tiempos, fallo y recuperación antes de mapear campos; después convierto los datos operativos en señales sobre las que el negocio puede actuar de verdad.
Un mismo entorno comercial, leído de tres maneras: quién responde de cada estado, cómo se mueve y cómo se concilian ambos lados cuando no coinciden.
- CRMEstado comercialCuentas, oportunidades, aprobaciones… y el estado que ven los comerciales
- Capa de integraciónEstado de entregaPeticiones, correlación, reintentos y estado de entrega; nunca la verdad de negocio
- ERPEstado legal / transaccionalClientes legales, pedidos y facturas
- Plataforma de datosEstado histórico / derivadoHistórico conformado, linaje y medidas derivadas
- Analítica y activaciónSeñal publicadaDefiniciones de métricas, segmentos y las señales que se escriben de vuelta
- CRM → a Capa de integraciónEvento Comando de alta
- Capa de integración → a CRMEvento Estado
- Capa de integración → a ERPAPI Alta idempotente
- ERP → a Capa de integraciónEvento Resultado
- CRM → a Plataforma de datosEvento Cambios de pipeline
- ERP → a Plataforma de datosBatch Pedidos y facturas
- Plataforma de datos → a Analítica y activaciónBatch Derivar a diario
- Analítica y activación → a CRMBatch Writeback: segmento y KPI · conciliado
- CRM ↔ y ERPConciliar por clave de petición · a diario
No es cablear APIs. Es un contrato de estado de negocio.
No trato la integración como «mapear el campo A al campo B y llamar a la API». El trabajo consiste en decidir qué significa cada hecho, quién es su responsable, cómo se mueve y cómo sabe todo el mundo que ha llegado.
Cablear APIsMapear camposAutomatización punto a puntoCopiar todos los campos del ERP en el CRMDashboards sobre definiciones inconsistentesReintentar llamadas fallidas hasta que «funcionen»
- AutoridadAsignar quién puede crear, cambiar y derivar cada hecho.
- IdentidadMantener reconocible una misma entidad de negocio en todos los sistemas.
- ContratosDefinir evento, payload, significado, versión y validación.
- Modo de interacciónElegir síncrono, asíncrono o batch según la tolerancia del negocio.
- Estado de entregaMostrar si una transferencia ocurrió de verdad.
- Semántica de falloDistinguir entre fallido, rechazado y desconocido.
- IdempotenciaHacer seguros por diseño todos los reintentos y reejecuciones.
- ConciliaciónDetectar la divergencia silenciosa de forma programada, con responsables.
- VersionadoCambiar contratos sin romper a sus consumidores.
- LinajeTrazar cada valor derivado hasta sus fuentes.
- Contratos de métricaUna definición, granularidad, responsable y frescura por métrica.
- ActivaciónHacer llegar una señal a alguien que actúa sobre ella.
- 01Un timeout no es lo mismo que un fallo.
Quien llama puede no saber si el sistema receptor llegó a confirmar la transacción.
Resultados desconocidos - 02Reintentar sin idempotencia es duplicar por diseño.
Una segunda petición para la misma intención de negocio no debe crear un segundo cliente, pedido o tarea.
Resultados desconocidos - 03«La fuente de referencia» suele ser poco granular.
La autoridad existe por concepto de negocio —a veces por atributo— y puede moverse con el ciclo de vida.
Autoridad del dato - 04Una métrica sin responsable ni acción es ruido de reporting.
Una métrica es un contrato operativo: definición, granularidad, frescura, responsable y la decisión que debería cambiar.
Contratos de métrica
Del evento de negocio a la señal gobernada.
Diez movimientos desde lo que ocurrió en el negocio hasta lo que alguien debería hacer al respecto. El mapeo de campos llega después de los cuatro primeros; los dashboards, después de todos.
01Identificar el evento de negocio
¿Qué ha ocurrido realmente en el negocio?
Las integraciones transportan eventos, no tablas.
- Prospecto aprobado
- Cliente creado
- Pedido confirmado
- Factura contabilizada
- Objetivo de ventas publicado
Una integración sin un evento de negocio con nombre acaba sincronizando todo lo que cambia—ruido incluido
Identificar el evento de negocio
¿Qué ha ocurrido realmente en el negocio?
Las integraciones transportan eventos, no tablas.
- Prospecto aprobado
- Cliente creado
- Pedido confirmado
- Factura contabilizada
- Objetivo de ventas publicado
Modelo de eventos de negocioUna integración sin un evento de negocio con nombre acaba sincronizando todo lo que cambia—ruido incluido
Definir la autoridad
¿Qué sistema es la referencia para cada concepto?
Por concepto, o por atributo cuando haga falta—no por sistema.
- Crear
- Actualizar
- Leer
- Derivar
Matriz de autoridad del datoLa autoridad puede moverse con el ciclo de vida: una propuesta del CRM se convierte en un hecho del ERP al crearse
Definir la identidad
¿Cómo saben los sistemas que hablan de lo mismo?
La identidad se diseña; no se empareja por nombres a posteriori.
- Identidad canónica
- IDs de sistema
- Claves naturales
- IDs de correlación
- Reglas de duplicados
- Fusión y baja
Modelo de identidadLa mayoría de los defectos de integración son defectos de identidad disfrazados
Definir el contrato
¿Qué se intercambia exactamente?
Un contrato es significado más forma, no un endpoint.
- Payload
- Significado semántico
- Campos obligatorios
- Campos opcionales
- Versión
- Validación
- Reglas de compatibilidad
Contrato de integraciónUn payload sin versión convierte cada cambio en una release coordinada
Elegir el modo de interacción
¿Con qué rapidez debe saberlo el sistema receptor?
Se elige por la tolerancia del negocio, no por moda.
- Síncrono
- Asíncrono / evento
- Batch
Patrón de interacciónEl tiempo real tiene un coste; necesita una decisión que pierda valor si se retrasa
Definir el estado de entrega
¿Cómo sabemos si la transferencia ocurrió de verdad?
El estado de entrega es visible para quienes dependen de él.
- Pendiente
- Enviado
- Recibido
- Confirmado
- Fallido
- Desconocido
- Conciliado
Modelo de estados de entregaRecibido no es confirmado: la recepción no es un resultado de negocio
Diseñar fallos y recuperación
¿Qué ocurre cuando el resultado es incierto?
Diseñar el resultado desconocido antes que el camino feliz.
- Reintento
- Idempotencia
- Reprocesamiento
- Gestión de mensajes fallidos
- Escalado
- Reparación manual
- Responsable
Diseño de la recuperaciónReintentar sin idempotencia es duplicar por diseño
Conciliar
¿Cómo detectamos una divergencia silenciosa?
La conciliación es un control permanente, no una limpieza.
- Población esperada
- Clave de comparación
- Tolerancia
- Frecuencia
- Responsable de las discrepancias
- Acción de reparación
Modelo de conciliaciónLas alertas ven las llamadas fallidas; solo la conciliación ve los registros que nunca llegaron
Dar forma al dato analítico
¿Qué debe guardarse de forma operativa, histórica y analítica?
Primero el grano; después, las medidas.
- Hechos
- Dimensiones
- Grano
- Histórico en un momento dado
- Medidas derivadas
- Linaje de origen
Modelo de datos analíticoUn CRM usado como warehouse se vuelve más lento y sigue sin poder responder «¿a fecha de cuándo?»
Publicar señales gobernadas
¿Qué métrica debería cambiar qué decisión?
Una métrica es un contrato operativo, no una fórmula.
- Contrato de métrica
- Responsable
- Frescura
- Definición
- Umbral
- Acción
- Destino de activación
Modelo señal–acciónUna métrica sin responsable ni acción es ruido en los informes
Los síntomas llegan como «la sincronización está rota».
Duplicados, estados desactualizados y tres versiones del mismo KPI. Debajo, nunca se definió un contrato, una clave o un responsable.
Un timeout se registra como fallo… y alguien vuelve a pulsar «Crear».
Lo que suele faltarUn estado de resultado desconocido y un reintento idempotenteLos reintentos crean clientes y pedidos duplicados en los sistemas destino.
Lo que suele faltarClaves de idempotencia ligadas a la petición de negocioLos usuarios no saben si un registro se ha sincronizado.
Lo que suele faltarEstado de entrega expuesto en términos de negocioCRM y ERP discrepan sobre el estado de un mismo cliente.
Lo que suele faltarAutoridad a nivel de atributo y una conciliación diariaCada equipo calcula el mismo KPI de forma distinta.
Lo que suele faltarUn único contrato de métrica con responsableEl CRM se ha convertido en un almacén de datos histórico.
Lo que suele faltarUna frontera entre datos operativos y analíticosUn job batch termina con éxito mientras falta en silencio parte de la población.
Lo que suele faltarCompletitud comprobada contra una población esperadaLos payloads cambian sin aviso y rompen a sus consumidores.
Lo que suele faltarContratos versionados con reglas de compatibilidad
Artefactos que hacen los datos lo bastante fiables para actuar.
Cada uno responde a una pregunta que el mapeo de campos deja abierta.
- Catálogo de eventos de negocio¿Qué ha pasado realmente en el negocio y quién necesita saberlo?
- Contrato de integración¿Qué payload, significado, versión y validación cruzan la frontera?
- Matriz de autoridad por sistema y atributo¿Quién puede crear, actualizar, leer o derivar cada concepto?
- Modelo de identidad¿Qué claves prueban que dos sistemas hablan de lo mismo?
- Topología de integración¿Qué sistemas intercambian qué, y a través de qué capa?
- Modelo síncrono / asíncrono / batch¿Con qué rapidez debe saberlo el receptor y qué puede continuar mientras tanto?
- Modelo de estados de entrega¿Cómo sabe todo el mundo si una transferencia se produjo?
- Estrategia de idempotencia¿Por qué un reintento o una reejecución nunca pueden crear dos veces?
- Modelo de recuperación y reenvío¿Quién repara qué y cómo se hace seguro el reenvío?
- Diseño de la conciliación¿Qué población se compara, con qué clave, cada cuánto y con qué responsable?
- Modelo de observabilidad¿Qué estados de negocio se monitorizan, más allá de llamadas y jobs?
- Modelo de granularidad analítica¿Qué significa una fila y a qué granularidad se encuentran los hechos?
- Contrato de métricaDefinición, responsable, frescura… y la acción que debería cambiar.
- Modelo de linaje¿Qué fuentes, reglas y versiones produjeron este valor?
- Flujo de activación del dato¿Dónde aterriza una señal y quién actúa sobre ella?
Un flujo, seis capas de contrato.
El alta de cliente, desde la aprobación en el CRM hasta el estado que ve el comercial. Lee una capa a lo largo de todo el flujo o abre un paso para ver las seis.
- Cliente aprobado: ID de cuenta del CRM, más una clave de petición generada una sola vez y ligada a la entidad legal.
- Alta de cliente solicitada: Clave de petición para la idempotencia; ID de correlación para trazar cada salto.
- Validación del cliente: Primero se comprueban las claves naturales —número de registro, identificación fiscal, país— para detectar un cliente existente.
- Cliente creado / rechazado: El número de cliente del ERP queda vinculado a la clave de petición y al ID de cuenta del CRM.
- Actualización de estado visible: Referencia cruzada guardada: cuenta ↔ entidad legal ↔ cliente del ERP.
Alta de cliente solicitada
- Evento de negocio
- Un comando, no un hecho: por favor, crea este cliente legal.
- Payload
- Contrato v2: razón social, números de registro e identificación fiscal, dirección de facturación, sociedad vendedora, divisa y clave de petición. Campos obligatorios y opcionales declarados; los campos desconocidos se rechazan.
- Identidad
- Clave de petición para la idempotencia; ID de correlación para trazar cada salto.
- Autoridad
- La capa de integración responde de la entrega, no del dato que transporta.
- Estado de entrega
- Pendiente → Enviado → Recibido. Recibido significa aceptado de forma duradera, no creado.
- Resultado
- Recepción confirmada. El resultado de negocio sigue abierto.
01Cliente aprobadoCRM
- Evento de negocio
- Se registra la aprobación comercial: este prospecto puede convertirse en cliente legal.
- Payload
- Todavía no sale nada. El CRM congela una instantánea inmutable de la petición aprobada.
- Identidad
- ID de cuenta del CRM, más una clave de petición generada una sola vez y ligada a la entidad legal.
- Autoridad
- El CRM responde de la aprobación y de la cuenta comercial.
- Estado de entrega
- Sin iniciar.
- Resultado
- El comercial ve «Alta solicitada».
02Alta de cliente solicitadaCapa de integración
- Evento de negocio
- Un comando, no un hecho: por favor, crea este cliente legal.
- Payload
- Contrato v2: razón social, números de registro e identificación fiscal, dirección de facturación, sociedad vendedora, divisa y clave de petición. Campos obligatorios y opcionales declarados; los campos desconocidos se rechazan.
- Identidad
- Clave de petición para la idempotencia; ID de correlación para trazar cada salto.
- Autoridad
- La capa de integración responde de la entrega, no del dato que transporta.
- Estado de entrega
- Pendiente → Enviado → Recibido. Recibido significa aceptado de forma duradera, no creado.
- Resultado
- Recepción confirmada. El resultado de negocio sigue abierto.
03Validación del clienteERP
- Evento de negocio
- El ERP valida los datos legales y fiscales antes de que exista un cliente.
- Payload
- El ERP trabaja sobre la instantánea; nunca vuelve a llamar al CRM para pedir más datos.
- Identidad
- Primero se comprueban las claves naturales —número de registro, identificación fiscal, país— para detectar un cliente existente.
- Autoridad
- Solo el ERP decide si existe un cliente legal, y con qué número.
- Estado de entrega
- A la espera del resultado. Un timeout aquí es Desconocido, no Fallido.
- Resultado
- Creado, rechazado con un motivo estable… o desconocido hasta conciliarlo.
04Cliente creado / rechazadoERP → integración
- Evento de negocio
- Un evento de resultado con la misma clave de petición.
- Payload
- Creado: número de cliente del ERP, sociedad y datos legales validados. Rechazado: código de motivo, campo y responsable de la corrección.
- Identidad
- El número de cliente del ERP queda vinculado a la clave de petición y al ID de cuenta del CRM.
- Autoridad
- A partir de aquí, la razón social y la dirección de facturación tienen el ERP como referencia.
- Estado de entrega
- Confirmado… o Fallido con un motivo de negocio.
- Resultado
- Un resultado legible para el negocio, no una traza de pila.
05Actualización de estado visibleCRM
- Evento de negocio
- El CRM registra el resultado sobre el que puede actuar el comercial.
- Payload
- El número de cliente y los campos validados llegan en solo lectura; un rechazo muestra su motivo y su responsable.
- Identidad
- Referencia cruzada guardada: cuenta ↔ entidad legal ↔ cliente del ERP.
- Autoridad
- El CRM deja de editar los atributos cuya referencia es el ERP y pasa a mostrarlos.
- Estado de entrega
- Conciliado a diario con el ERP por clave de petición.
- Resultado
- El comercial puede lanzar el pedido… o ve exactamente quién está corrigiendo qué.
Un endpoint dice adónde enviar una petición. El contrato dice qué significa, de quién trata, quién puede cambiar qué, cómo sabe todo el mundo que ha llegado… y qué pasa cuando no llega.
¿Con qué rapidez debe enterarse el receptor?
Síncrono, asíncrono y batch encajan cada uno con una tolerancia distinta del negocio a la espera, a la inconsistencia y a la pérdida. Se empieza por una petición, no por una tecnología.
Evento Asíncrono / evento
La validación puede tardar minutos o requerir a una persona. El CRM continúa en un estado pendiente visible; el resultado llega como evento.
Lo que el negocio acepta: Consistencia eventual, un modelo de estados de entrega y una conciliación diaria.
- API
Síncrono
Petición–respuesta- Mejor cuando
- Se necesita una respuesta inmediata
- La operación es corta
- Quien llama puede esperar sin riesgo
- Vigilar
- Acoplamiento a la disponibilidad del receptor
- Latencia que nota el usuario
- Timeouts con un resultado incierto
- Necesita
- Un presupuesto de timeout
- Reintento idempotente
- Una vía degradada cuando el receptor está caído
- Evento
Asíncrono / evento
Comando o evento, resultado más tardeEncaja con esta petición- Mejor cuando
- El proceso puede continuar en estado pendiente
- La operación es larga o propensa a fallos
- La resiliencia importa más que la inmediatez
- Vigilar
- Consistencia eventual que los usuarios deben entender
- Entregas desordenadas o duplicadas
- Pérdidas silenciosas si nada lo comprueba
- Necesita
- Correlación
- Estado de entrega visible
- Reintento y reenvío
- Conciliación
- Batch
Batch
Una población, según calendario- Mejor cuando
- Se acepta una frescura menor
- Importa procesar toda la población
- Ingesta histórica o analítica
- Vigilar
- Cargas parciales que informan de éxito
- Registros que llegan tarde
- Ventanas de recuperación largas
- Necesita
- Controles de completitud
- Una marca de agua o un cursor
- Capacidad de reinicio
- Conciliación
Ninguno de los tres es más moderno que los otros. La arquitectura sigue la tolerancia del negocio a la espera, a la inconsistencia y a la pérdida.
Un timeout no es lo mismo que un fallo.
Quien llama puede no saber si el sistema receptor llegó a confirmar la transacción. Ese momento se diseña antes que el camino feliz.
- Petición enviadaCrear cliente · clave de petición REQ-7F3A
- TimeoutSin respuesta dentro del plazo
FallidoDesconocidoQuien llama no puede saber si el ERP la confirmó
Correcto: Cliente creado una vez.
Incorrecto: Se crea un segundo cliente legal. Pedidos y facturas quedan repartidos entre los dos.
Solo funciona si el primer intento falló de verdad, y quien llama no puede saberlo.
- Clave de idempotencia
Una clave por intención de negocio, ligada a la entidad legal. El receptor crea como mucho una vez por clave.
- +Correlación
Cada salto lleva el mismo ID de correlación, de modo que cada resultado se asocia a su petición sin adivinar.
- +Conciliación
Lo que el proceso de resolución no puede cerrar se compara a diario y tiene un equipo responsable con nombre.
Reintentar sin idempotencia es duplicar por diseño. Una segunda petición para la misma intención de negocio nunca debe crear un segundo cliente, pedido o tarea.
Estado de entrega, visible para quien depende de él
Desconocido
Timeout o respuesta perdida. La petición puede haberse confirmado o no.
- El comercial ve
- «Confirmando el resultado»
- Puede pasar a
- Conciliado
- Responsable
- Operaciones de integración
Observar el estado de negocio, no solo las llamadas
Estado técnico: HTTP 202 Accepted→Estado de negocio: Alta de cliente solicitadaEstado técnico: Mensaje entregado en la cola→Estado de negocio: Validación del cliente pendienteEstado técnico: HTTP 200 con cuerpo de error→Estado de negocio: Alta de cliente rechazada: número de registro duplicadoEstado técnico: Timeout de socket tras 30 s→Estado de negocio: Alta de cliente desconocida: conciliandoEstado técnico: HTTP 200 OK→Estado de negocio: Cliente creado: número emitidoEstado técnico: Job nocturno completado→Estado de negocio: Faltan en la carga las facturas de una sociedad
Recuperación, con responsable
- Reintento Solo ante fallos transitorios, con backoff y un presupuesto, y siempre con la misma clave.
- Reenvío Volver a enviar una petición o un evento almacenado; es seguro porque el receptor es idempotente.
- Dead-letter Los mensajes envenenados salen del flujo con su motivo, para que un registro erróneo no bloquee al resto.
- Escalado Los desconocidos y los dead letters que superan su umbral avisan a un responsable con nombre.
- Reparación manual Un formulario en el sistema responsable —nunca una edición directa en base de datos— seguido de un reenvío.
La conciliación es parte de la arquitectura.
Las garantías de entrega fallan en silencio. Una comparación programada entre la población esperada y la real —con un responsable para cada tipo de diferencia— es lo que hace visible la divergencia silenciosa.
| Clave | Esperado · CRM | Real · ERP | Resultado |
|---|---|---|---|
REQ-1041 | Creado · ERP 30071 | Creado · ERP 30071 | CoincideAmbos lados coinciden. |
REQ-1042 | Pendiente | Creado · ERP 30072 | DiferenciaSe perdió el evento de resultado; el CRM nunca recibió respuesta. |
REQ-1043 | Dirección de facturación v3 | Dirección de facturación v2 | DiferenciaUn cambio de dirección posterior al alta nunca llegó al ERP. |
REQ-1044 | Solicitado | — | FaltaLa petición nunca llegó; está atascada antes del ERP. |
— | — | ERP 30090 · sin clave de petición | InesperadoSe creó un cliente directamente en el ERP, fuera del proceso. |
REQ-1046 | Creado · ERP 30074 | Creado · ERP 30074 | CoincideAmbos lados coinciden. |
- Coincide
Misma identidad, mismo estado, dentro de la tolerancia.
- Responsable
- Nadie
- Acción
- Registrar la comprobación; nada más.
- Diferencia
Misma identidad, distinto estado o atributo.
- Responsable
- Operaciones de integración
- Acción
- Aplicar el valor del lado de referencia; reenviar el resultado.
- Falta
Esperado en un lado, ausente en el otro.
- Responsable
- Operaciones de integración
- Acción
- Consultar por clave de petición; reenviar con la misma clave o cerrar como rechazado.
- Inesperado
Presente en un lado sin contrapartida esperada.
- Responsable
- Gobierno de datos maestros
- Acción
- Vincularlo a una cuenta o señalar un alta fuera de proceso.
El contrato de conciliaciónPoblación, clave, tolerancia, frecuencia y responsable, definidos antes de la primera ejecución
- Población esperada
- Cuentas del CRM con una petición de alta en los últimos 30 días
- Clave de comparación
- Clave de petición y, después, número de cliente del ERP
- Se compara
- Identidad · estado de negocio · dirección de facturación · marca de tiempo
- Tolerancia
- Un pendiente de menos de 2 horas no es una diferencia
- Frecuencia
- Diaria, y bajo demanda tras una caída
- Responsable
- Operaciones de integración; reparaciones por tipo
Qué es cierto ahora, qué ha pasado y qué hacer al respecto.
Los sistemas operativos responden qué es cierto ahora. La plataforma analítica responde qué ha pasado a lo largo del tiempo. La activación responde qué debería hacer alguien a raíz de ello.
- CRM · ERP
- ¿Qué es cierto ahora?
- ¿Qué acción debería ocurrir ahora?
- Plataforma de datos · data warehouse
- ¿Qué ha pasado a lo largo del tiempo?
- ¿Cómo se deriva el rendimiento?
- ¿Cómo se comparan los sistemas?
- CRM · campañas · workflows
- ¿Qué debería hacer alguien a raíz de la señal?
- 01Transacciones
Pedidos, facturas, oportunidades: el estado actual en el sistema que responde de ellos.
- 02Histórico
Cada versión conservada, fechada, a una granularidad declarada.
- 03Derivación
Medidas calculadas una sola vez, a partir de una única definición.
- 04Señal
Un valor publicado y versionado, con su sello de frescura.
- 05Acción
Una tarea, campaña o decisión con una persona responsable.
Linaje: cada paso con una definición, un responsable y una versión
% de rendimiento frente a objetivo
- Definición
- (Facturado + pedidos abiertos) ÷ objetivo, en lo que va de año.
- Responsable
- Operaciones de ventas
- Versión y momento
- Definición de la métrica v3
Una métrica sin responsable ni acción es ruido de reporting.
Una métrica es un contrato operativo, no una fórmula: una definición, una granularidad, una promesa de frescura, un lugar donde se calcula, un lugar donde aterriza… y la decisión que debería cambiar.
Cobertura de pipeline
Pipeline abierto elegible ÷ objetivo restante del periodo
- Granularidad
- Cuenta · segmento · periodo
- Entradas
- OportunidadObjetivo
- Responsable
- Operaciones de ventas
- Frescura
- Diaria
- Se calcula en
- Plataforma de datos
- Se activa en
- CRM
Por debajo de 3× el objetivo restante
Generar pipeline allí donde la cobertura cae por debajo del umbral
Un dato no aporta valor hasta que cambia una acción
- Señal: Cuenta en riesgoResponsable: Responsable de la cuentaAcción: Plan de recuperaciónResultado: Rendimiento de nuevo por encima del umbral
- Señal: Cobertura de pipeline bajaResponsable: Jefe de ventasAcción: Acción de generación de pipelineResultado: Cobertura restablecida para el periodo
- Señal: Sin ventaResponsable: Campaña comercialAcción: Tarea de reactivaciónResultado: Primer pedido tras la reactivación
Cinco flujos, cinco dimensiones del dato.
Escenarios B2B globales sintéticos. El caso principal CRM–ERP se lee aquí desde su vertiente de integración; cuatro casos nuevos cubren granularidad, writeback, conciliación y evolución a varias divisas.
- Caso 01Caso seleccionadoIdentidad · entrega asíncrona · resultado desconocido · conciliación
Diseñar el ciclo de vida del cliente entre CRM y ERP
Una petición de alta puede agotar su timeout cuando el ERP ya la ha confirmado, así que un reintento ingenuo crea un segundo cliente legal.
¿Qué significa un timeout, y cómo se resuelve el resultado sin crear un duplicado?
CRMCapa de integraciónERPArquitectura de Sistemas y CRMArquitectura de Procesos - Caso 02Caso seleccionadoGranularidad, identidad y frescura
Convertir transacciones del ERP y objetivos en inteligencia comercial
Pedidos, facturas y objetivos llegan de sistemas distintos, con granularidades y tiempos distintos, así que cada informe responde a una pregunta ligeramente diferente.
¿Cuál es la granularidad de cada hecho, y dónde se encuentran sin contar dos veces?
ERPPlanificaciónCRMPlataforma de datosRevenue OperationsArquitectura de Sistemas y CRM - Caso 03Writeback, frescura y activación
Devolver señales analíticas al CRM operativo
El rendimiento se calcula fuera del CRM, pero los comerciales actúan dentro, así que las cifras que ven están desactualizadas, se pueden editar o nadie las explica.
¿Debe el CRM guardar una copia de la métrica, y quién responde de ella cuando llega?
Plataforma de datosCapa de integraciónCRMRevenue OperationsAutomatización - Caso 04Población, bajas y reejecuciones idempotentes
Diseñar una segmentación fiable con conciliación
Hay cuentas que acaban con dos segmentos o con ninguno, y las campañas siguen dirigiéndose a cuentas que ya se han recuperado.
¿Cómo tiene cada cuenta elegible exactamente un segmento vigente, y cada reejecución sigue siendo segura?
Plataforma de datosCRMPlataforma de campañasRevenue OperationsAutomatización - Caso 05Evolución: modelo de importes V1 → V2
Evolucionar la analítica comercial de una sola divisa a varias
La primera versión informaba en una sola divisa. Las filiales que venden en otras amenazan ahora cada total, cada umbral y cada informe histórico.
¿Qué importe es el hecho, cuál es una vista, y se puede seguir reproduciendo el informe del año pasado?
ERPServicio de tipos de cambioPlataforma de datosCRMRevenue OperationsArquitectura de Sistemas y CRM
Toda petición de datos tiene una segunda capa.
La petición visible es donde empieza el diseño, no donde termina.
“Sincronizar los clientes con el ERP.”
Mapear los campos de la cuenta al cliente del ERP y llamar a su API al guardar.
4 de 6 preguntas a la vista
El CRM, de la cuenta; datos maestros, de la entidad legal; cada ERP, de su número de cliente. Vinculados, no fusionados.
Los sistemas definen la responsabilidad. Los datos la mueven y la concilian.
Datos e Integraciones
- Arquitectura de Sistemas y CRM
Sistemas define la responsabilidad: qué plataforma responde de qué concepto. Datos e Integraciones mueve y concilia ese estado.
- Arquitectura de Procesos
El proceso define los eventos y las decisiones de negocio que transportan las integraciones.
- Revenue Operations
Revenue Operations convierte las señales gobernadas en acción: cobertura, recuperación, reactivación.
- Automatización
La automatización ejecuta el comportamiento posterior —tareas, inscripciones, actualizaciones— una sola vez por señal.
- IA y Flujos Agénticos
La IA depende de una identidad y un contexto fiables; un agente hereda cada ambigüedad del dato.
- Modelo Operativo Digital
Los responsables de definiciones, conciliación y reparación salen del modelo operativo.
Decisiones de arquitectura
Trabajo relacionado
Una integración no es una tubería. Es un contrato que define
- Identidad
- Autoridad
- Evento
- Payload
- Tiempos
- Estado de entrega
- Fallo
- Recuperación
- Conciliación
Y la arquitectura de datos no termina cuando llegan los datos.
Continúa a través del histórico, la derivación, una métrica gobernada y la activación, hasta que alguien actúa.
Dos sistemas que no coinciden—y nadie sabe cuál tiene razón.
- ¿Qué significa hoy un timeout en tu integración?
- ¿Qué KPI tiene tres definiciones y ningún responsable?
- ¿Qué encontraría una conciliación diaria?