Arquitectura de datos de ingresos: el diseño en 30 días

La arquitectura de datos de ingresos es el diseño que dice en qué sistema vive cada entidad de la operación comercial, como cuenta, contacto, negocio, pedido, contrato y ticket, qué clave identifica al mismo cliente en todos los sistemas, hacia dónde viaja cada dato y con qué frecuencia. Sin ese diseño, cada área responde por su propia versión de la verdad, y la dirección pasa la reunión discutiendo qué número es el correcto. El costo llega a la caja: en la encuesta de cultura y alfabetización en datos de Forrester de 2023, más de una cuarta parte de los profesionales de datos y analítica que señalan la mala calidad de los datos como obstáculo estimaron pérdidas de más de 5 millones de dólares al año, y el 7% habló de 25 millones o más (Forrester, 2024). Diseñar la arquitectura no exige comprar un sistema. Exige que la dirección decida, entidad por entidad, quién es el dueño, y sostenga la decisión el día en que un área quiera editar lo que pertenece a otra.

En un ejemplo hipotético, el director comercial presenta R$ 2,4 millones de ingresos nuevos en el trimestre, la suma de los negocios ganados en el CRM. Finanzas muestra R$ 1,9 millones en el ERP, porque R$ 300 mil se firmaron en la última semana y todavía no se facturaron, y otros R$ 200 mil tienen la primera cuota prevista para el trimestre siguiente. La planilla de posventa trae R$ 2,2 millones, porque excluye dos contratos de R$ 100 mil que los clientes cancelaron durante la implementación y que el CRM todavía muestra como ganados. Los tres números son correctos según la regla de cada área, y la reunión gasta cuarenta minutos conciliando. Gartner señala la inconsistencia entre fuentes, resultado de datos guardados en silos con superposiciones y vacíos, como el problema de calidad de datos más difícil de enfrentar (Gartner, 2024).

¿Qué es la arquitectura de datos de ingresos?

La arquitectura de datos de ingresos es el conjunto de decisiones que organiza la información de marketing, ventas, finanzas y posventa alrededor de las mismas entidades. Entidad, en este contexto, es cada tipo de cosa que la operación registra y cuenta: la empresa cliente, la persona con la que hablas, la oportunidad en negociación, el pedido facturado, el contrato firmado y el caso de soporte abierto. El diseño tiene cinco partes: el sistema dueño de cada entidad, los sistemas que la leen, la clave que une los registros, la frecuencia de las sincronizaciones y la capa donde la dirección consume los números.

La elección de las herramientas va en otro documento: en stack de ventas trato las capas, el dato que cada herramienta devuelve al CRM y el criterio para cortar licencias. La arquitectura vale para cualquier combinación de herramientas y responde a otra pregunta: cuando el mismo cliente aparece en seis sistemas, qué registro vale, cómo sabes que es el mismo cliente y en cuánto tiempo un cambio llega a los demás.

¿Qué sistemas entran en la arquitectura de datos?

Entran todos los lugares donde alguien registra información que después se convierte en número de dirección. El CRM guarda la relación comercial, la automatización de marketing guarda el origen del lead y el consentimiento, y el ERP guarda el registro fiscal, los pedidos, las facturas y los pagos. La herramienta de atención guarda los casos de soporte, y el sistema del producto, cuando la empresa vende software o un servicio con uso medido, guarda quién lo usa y cuánto.

Dos piezas suelen quedar fuera del mapa y son las que más distorsionan el resultado. La primera son las planillas: la cartera de posventa y el control de comisiones funcionan como sistemas, con dueño y reglas propias, y la arquitectura decide si cada una se convierte en fuente oficial, migra a un sistema o sale de circulación. La segunda es el BI, la capa de análisis que cruza los sistemas y publica los tableros. El BI solo lee y no es dueño de ninguna entidad, y la corrección hecha directo en el tablero desaparece en la siguiente carga.

¿Cuál es la fuente de verdad de cada entidad?

La fuente de verdad, o sistema de registro, es el sistema donde nace la entidad, donde ocurren los cambios oficiales y cuya versión prevalece cuando dos sistemas discrepan. La regla que sostiene el diseño es un dueño por entidad, o por grupo de atributos dentro de ella. Los otros sistemas leen y pueden mostrar la información, sin editarla. La tabla de abajo es el instrumento que llevo a la primera reunión con la dirección, y los líderes la completan con los sistemas de su propia empresa.

Entidad	Qué representa	Sistema dueño	Sistemas que la leen	Clave	Frecuencia
Cuenta	La empresa cliente o prospecto	CRM para datos comerciales; ERP para razón social, CNPJ y domicilio fiscal	Automatización, atención, producto y BI	ID maestro del cliente, con CNPJ	Al crearla y diaria
Contacto	La persona en la empresa cliente	CRM; automatización para el consentimiento	Automatización, atención y herramientas de conversación	Correo corporativo	Continua
Negocio	La oportunidad en negociación	CRM	BI y propuestas	ID del negocio en el CRM	Continua
Pedido	Lo que se vendió y se va a facturar	ERP	CRM y BI	Número de pedido, con el ID del negocio de origen	Al ganar y diaria
Contrato	Vigencia, valor, reajuste y condiciones	Herramienta de firma o jurídico, con copia en el ERP	CRM, ERP, atención y BI	Número de contrato, con ID maestro del cliente	Al firmar
Ticket	El caso abierto por el cliente	Herramienta de atención	CRM y BI	ID del ticket, con ID maestro del cliente	Diaria
Uso del producto	Lo que el cliente hace en el producto o servicio	Sistema del producto	CRM, atención y BI	ID maestro del cliente	Diaria
Factura y pago	Factura emitida, vencimiento y cobro	ERP	CRM, atención y BI	Número de factura, con número de pedido	Diaria

Cada fila toma minutos para completarse y a veces una semana para aprobarse, porque cierra una disputa entre áreas. Empieza por las entidades que aparecen en los números de la dirección.

Cuando la entidad tiene dos dueños

La cuenta es el caso clásico de dueño dividido. El ERP manda en los atributos fiscales, porque la factura sale con la razón social y el CNPJ (el número de registro fiscal de las empresas en Brasil) que finanzas validó, y el CRM manda en los atributos comerciales, como segmento, tamaño, dueño de la cartera y etapa del cliente. La división funciona cuando está escrita atributo por atributo y la integración respeta la dirección: el vendedor encuentra la razón social bloqueada en el CRM y le pide la corrección a finanzas. Sin ese bloqueo, la carga siguiente devuelve el valor antiguo, y el equipo concluye que el sistema no funciona.

Pedido y contrato cuentan ingresos distintos

El contrato dice cuánto se comprometió a pagar el cliente y por cuánto tiempo, y alimenta el ingreso contratado y la renovación. El pedido dice qué se va a facturar y cuándo, y alimenta el ingreso facturado y la caja. La dirección necesita los dos números con nombres distintos, y la arquitectura une cada pedido con el contrato y el negocio de origen, para que expliques la diferencia sin armar una planilla. El recorrido del negocio ganado hasta el primer pago está en lead to cash.

¿Cómo definir la clave única del cliente?

La clave única del cliente es el identificador que permite afirmar que el registro del CRM, el alta en el ERP, la cuenta en la herramienta de atención y el usuario del producto son la misma empresa. Sin ella, el BI cruza los sistemas por el nombre, y “Grupo Alfa Ltda.”, “Alfa” y “ALFA INDUSTRIA” se convierten en tres clientes. En el B2B brasileño, el CNPJ es el punto de partida natural, y por sí solo no resuelve el problema.

Los ocho primeros caracteres del CNPJ identifican a la empresa, los cuatro siguientes identifican el establecimiento y los dos últimos son dígitos verificadores. Un cliente con casa matriz y cuatro sucursales tiene cinco CNPJ, y la dirección necesita decidir si cuenta un cliente o cinco. Los grupos económicos complican más, porque empresas con raíces distintas pueden responder al mismo comprador. Te recomiendo crear un ID maestro del cliente, generado por un único sistema, en general el CRM o el ERP, y una tabla de correspondencia que guarde, para cada ID maestro, los identificadores del mismo cliente en cada sistema. El CNPJ entra como atributo validado, la raíz agrupa los establecimientos y un campo de grupo económico une las empresas que compran juntas.

El formato del campo también pide revisión ahora. Desde julio de 2026, la Receita Federal de Brasil asigna el CNPJ alfanumérico a las nuevas inscripciones, y los números existentes siguen válidos sin cambios (Receita Federal, 2024). Un campo de CNPJ configurado para aceptar solo números, o una integración que trata el CNPJ como número, rechaza el alta de clientes abiertos después de esa fecha. Para los contactos, la clave es el correo corporativo, y las reglas de registro y deduplicación que mantienen limpias esas claves están en calidad de datos en el CRM.

¿Con qué frecuencia debe sincronizar cada sistema?

La frecuencia correcta depende del tiempo que la decisión apoyada en ese dato puede esperar. El tiempo real cuesta más, se rompe con más facilidad y solo se paga cuando alguien actúa sobre el dato en minutos.

Patrón	Cómo funciona	Cuándo usarlo	Ejemplo en la operación
Por evento	El sistema dueño envía el cambio en el momento en que ocurre	La siguiente persona necesita actuar en minutos	Lead nuevo que entra en la fila del SDR; negocio ganado que crea el pedido en el ERP
Cada hora	Una rutina busca los cambios de la última hora	La información orienta el trabajo del día	Caso crítico que aparece en el registro de la cuenta para el vendedor
Diaria	Una carga nocturna lleva todo el día de una vez	La decisión ocurre en la reunión de la semana o del mes	Pagos, morosidad y uso del producto para el BI y el CRM
Foto de cierre	El BI congela los números a una hora acordada	El número oficial del período tiene que ser el mismo para todos	Ingresos del mes congelados el primer día hábil a las 10 h

La última fila resuelve una divergencia que poca gente nota: si comercial saca el informe a las 9 h y finanzas a las 15 h, los dos números difieren por lo que entró en el medio. La foto publicada en el BI, con hora escrita, le da a la dirección un número oficial por período.

¿Qué pasa cuando no hay arquitectura de datos?

La divergencia en la reunión de dirección tiene tres causas, y cada una pide una corrección distinta. La primera es la definición: “cliente activo” significa contrato vigente para posventa, factura pagada en los últimos noventa días para finanzas y negocio ganado para comercial. La segunda es la clave, que hace que el mismo cliente aparezca dos veces en una base y ninguna en la otra. La tercera es el tiempo, con sistemas sincronizados a horas distintas o sin sincronización. La arquitectura ataca las dos últimas, y la definición de cada indicador queda registrada en la matriz de métricas, como describo en métricas de RevOps.

El efecto más caro aparece en las decisiones. La dirección posterga la contratación porque no confía en el pronóstico, y marketing pierde presupuesto porque no logra probar el ingreso por origen. Cuando el número de la pantalla difiere de la planilla de la víspera, el liderazgo vuelve a la planilla, y el dashboard comercial pasa a decorar la sala.

La inteligencia artificial encarece la falta de diseño. El agente que resume la cuenta antes de la llamada lee el CRM, el ERP y la herramienta de atención, y si la clave no une los tres, resume la mitad del cliente con toda la confianza. En una encuesta a 1.203 líderes de gestión de datos realizada en julio de 2024, el 63% de las organizaciones dijo no tener, o no saber si tiene, las prácticas de gestión de datos adecuadas para IA, y Gartner prevé que, hasta 2026, las organizaciones abandonarán el 60% de los proyectos de IA sin datos preparados para IA (Gartner, 2025).

¿Quién es dueño de la arquitectura de datos de ingresos?

La arquitectura necesita un patrocinador en la dirección, porque cada fila del mapa le quita poder de edición a alguien, y solo la dirección arbitra esa disputa. Cada entidad tiene un dueño de negocio, el área del proceso donde nace el dato, y operaciones de ingresos mantiene el mapa mientras TI implementa integraciones y BI. En los diagnósticos que conduzco, la arquitectura que se sostiene es la que tiene el nombre de cada dueño escrito en el propio mapa, con la fecha de la última revisión.

Rol	Quién suele ser	Responde por	Aprueba
Patrocinador	Director de ingresos, CEO o CFO	Arbitrar conflictos entre áreas y exigir el mapa en la reunión de dirección	El mapa de entidades y las definiciones oficiales
Dueño de la entidad	Liderazgo del área donde nace el dato: ventas para negocio, finanzas para pedido y factura, posventa para ticket	Reglas de registro, atributos obligatorios y correcciones de la entidad	Cambios en los atributos de su propia entidad
Arquitecto de la operación	Operaciones de ingresos	Diseñar y mantener el mapa, la tabla de correspondencia y la frecuencia de cada flujo	Nuevas integraciones y nuevos campos que cruzan sistemas
Implementación técnica	TI o equipo de datos	Integraciones, seguridad, accesos y cargas del BI	Proveedores y la forma técnica de cada flujo
Responsable de la base	Administrador del CRM o analista de operaciones	Deduplicación, tabla de correspondencia y errores de las integraciones	Importaciones y fusiones de registros
Usuarios	Vendedores, analistas, agentes de atención y finanzas	Registrar en el sistema dueño y pedir la corrección al dueño de la entidad	Nada; señalan problemas

En empresas más chicas, una persona de operaciones acumula los roles de arquitecto y de responsable de la base, y TI puede ser un proveedor externo, pero el patrocinador sigue siendo indispensable. La estructura del equipo que sostiene este trabajo está en equipo de RevOps.

Errores comunes al diseñar la arquitectura de datos

Empezar por el BI

La empresa contrata la herramienta de BI esperando que concilie los números. Si los sistemas no comparten clave ni definición, el tablero nuevo muestra la misma divergencia con mejores gráficos, por eso el mapa y la clave van antes de cualquier tablero.

Dos sistemas editando la misma entidad

La integración en los dos sentidos parece la más completa y crea una disputa permanente: la corrección hecha en el CRM vuelve al valor antiguo cuando el ERP sincroniza. Cada atributo necesita un único sistema que lo edite, con los demás solo leyendo.

Usar el nombre de la empresa como clave

El nombre cambia con fusiones, con un nuevo nombre comercial y con la forma en que cada persona escribe. El cruce por nombre pierde clientes y crea duplicados que el responsable de la base tarda semanas en corregir.

Sincronizar todo en tiempo real

El tiempo real en todos los flujos multiplica costos y fallas, y la mayor parte de las decisiones de la dirección ocurre en reuniones semanales o mensuales. Reserva el envío por evento para quien actúa en minutos y usa carga diaria en el resto.

Diseñar sin finanzas

Los proyectos conducidos solo por marketing y ventas se detienen en el pedido y el contrato, que pertenecen a otra dirección. Finanzas participa desde la primera reunión, porque es dueña de las entidades que cierran la cuenta de los ingresos, y sus planillas entran en el mapa como sistemas.

¿Cómo preparar al equipo para sostener la arquitectura?

El mapa se vuelve rutina cuando cada persona sabe en qué sistema registra y a quién pide una corrección. Los líderes aprenden a leer el mapa y a exigir el número oficial en la reunión, rechazando la planilla paralela. El responsable de la base y la persona de operaciones aprenden a mantener la tabla de correspondencia y a revisar los errores de integración. Vendedores, analistas y agentes de atención necesitan una sesión corta, en el sistema de la empresa, sobre los campos bloqueados y el camino de la corrección. En las operaciones que acompaño, la mayor resistencia viene de quien perdió el permiso de editar un campo, y la explicación del motivo, dada por el propio dueño de la entidad, resuelve más que cualquier bloqueo técnico.

Hoja de ruta de 30 días para el liderazgo

En cuatro semanas el liderazgo diseña y decide, y la implementación de las integraciones queda para el trimestre siguiente, con el mapa aprobado.

1. Días 1 a 3: nombra al patrocinador y a quien conduce el diseño. La dirección comunica a las áreas que el mapa tendrá fuerza de regla.
2. Días 4 a 7: haz la prueba del número de la dirección. Clasifica cada diferencia entre áreas por definición, clave u hora.
3. Días 8 a 12: lista sistemas y planillas. Incluye toda planilla que alimenta una reunión de liderazgo, con su dueño.
4. Días 13 a 17: completa el mapa de entidades. Define sistema dueño, lectores, clave y frecuencia, con el dueño de cada área presente.
5. Días 18 a 20: decide la clave única del cliente. Elige quién genera el ID maestro, la regla de matriz, sucursal y grupo, y el formato del CNPJ.
6. Días 21 a 24: fija las frecuencias y la hora de la foto de cierre. Escribe la hora oficial de cada número de dirección.
7. Días 25 a 27: nombra a los dueños y aprueba el mapa. El patrocinador arbitra las filas en disputa.
8. Días 28 a 30: planifica implementación y formación. Ordena las integraciones por su impacto en los números de dirección y agenda las sesiones de cada perfil.

Si tu dirección pasa la reunión conciliando números en lugar de decidir, ese es el trabajo de la formación in company de Revenue Operations. Conduzco el programa con los liderazgos de marketing, ventas, posventa, finanzas y TI en la misma sala, sobre los sistemas y los números de tu operación. El grupo sale con el SLA entre marketing, ventas y CS, que define qué entrega cada área a la siguiente, y con la matriz de métricas de RevOps, que registra la definición de cada indicador y el sistema del que sale, la base para el mapa de entidades.

Preguntas frecuentes

¿Qué es la arquitectura de datos de ingresos?

Es el diseño que define en qué sistema vive cada entidad de la operación comercial, como cuenta, contacto, negocio, pedido, contrato y ticket, qué sistemas leen cada una, qué clave identifica al mismo cliente en todos ellos y con qué frecuencia se sincronizan los datos. Con ella, la dirección trabaja con un número oficial por indicador.

¿El CRM debe ser la fuente de verdad de todo?

El CRM es la fuente de verdad de la relación comercial, con contactos, negocios, actividades y dueño de la cartera. Pedido, factura y pago pertenecen al ERP, y los casos de soporte pertenecen a la herramienta de atención. El CRM muestra esos datos en el registro del cliente sin editarlos.

¿Cuál es la mejor clave única para clientes B2B en Brasil?

Un ID maestro generado por un único sistema, con el CNPJ como atributo validado y una tabla de correspondencia con los identificadores del cliente en cada sistema. La raíz del CNPJ agrupa matriz y sucursales, y un campo de grupo económico une empresas distintas que compran juntas. El campo de CNPJ necesita aceptar letras desde la llegada del formato alfanumérico.

¿Necesito un data warehouse para tener arquitectura de datos?

La arquitectura va antes de la herramienta y funciona con los sistemas que la empresa ya tiene. El data warehouse, una base que reúne los datos de varios sistemas para análisis, ayuda cuando crecen el volumen y la cantidad de fuentes, y hereda los problemas de clave y definición si el mapa no existe.

¿Quién debe aprobar el mapa de entidades?

El patrocinador en la dirección aprueba el mapa y arbitra las filas en disputa, y cada dueño de entidad aprueba las reglas de la suya. Operaciones de ingresos conduce el diseño y mantiene el documento actualizado, y TI valida la viabilidad técnica de cada flujo.

¿Cómo preparar al equipo para trabajar con la nueva arquitectura?

Empieza por los líderes, que necesitan leer el mapa y exigir el número oficial en la reunión. Después forma al responsable de la base y a la persona de operaciones en el mantenimiento de la clave y de las integraciones, y haz sesiones cortas con cada perfil de usuario sobre dónde registrar y a quién pedir correcciones. Mide por las planillas paralelas que dejan de circular y por el tiempo dedicado a conciliar en la reunión de dirección.