Cuando dos reportes del mismo negocio dan números distintos

Por qué el mismo KPI da resultados distintos según quién lo corra, cómo identificar si tu empresa tiene un problema de gobierno de datos, y qué hacer al respecto sin necesitar un proyecto de seis meses.

El director de operaciones abre el reporte del CRM un lunes a la mañana. Son 1.240 clientes activos. El gerente financiero llega a la reunión con el del ERP: 1.087. Nadie sabe cuál es el correcto. La reunión se convierte en una discusión sobre fuentes de datos en lugar de sobre el negocio.

Eso no es una anécdota de startup desordenada. Es la situación cotidiana de la mayoría de las empresas medianas en LATAM que tienen más de dos sistemas operativos funcionando en paralelo.

Y el problema no es que tengan muchos sistemas. Es que nadie definió las reglas del juego.

¿Qué es exactamente el gobierno de datos?

Antes de entrar en síntomas y soluciones, vale la pena sacar el término del territorio académico donde suele vivir.

Gobierno de datos no es un software. No es una certificación. No es el proyecto de tres años que le propone una consultora con diapositivas de marcos de referencia.

Es la respuesta a tres preguntas muy simples:

1. ¿Qué significa este dato? (la definición)
2. ¿De dónde viene? (la fuente y el proceso que lo genera)
3. ¿Quién es responsable de que sea correcto? (el dueño)

Cuando esas tres preguntas tienen respuesta documentada para los indicadores clave del negocio, tenés gobierno de datos. Cuando no la tienen, tenés el problema de los dos reportes.

Los síntomas que más se ven

Reportes que dan números distintos para la misma pregunta

Ya describimos este caso. Lo que lo causa es casi siempre una combinación de:

• Definiciones distintas del mismo concepto. “Cliente activo” en el CRM puede significar cualquiera que haya comprado en los últimos 12 meses. En el ERP puede significar cualquiera con una factura emitida en el trimestre. Los dos están “bien” según la lógica de cada sistema — pero no hablan de lo mismo.

• Lógica de cálculo no documentada. Alguien en sistemas construyó el reporte hace tres años. La persona ya no está. Nadie sabe exactamente qué hace el query. Todo el mundo lo usa.

• Datos que se transforman en distintos lugares. El mismo campo se limpia, se agrupa o se filtra de forma diferente en cada sistema que lo toca.

El KPI que “siempre lo usamos así”

Hay un número en cada empresa que nadie cuestiona porque “siempre fue así”. El margen real, el costo por operación, el nivel de servicio. En algún momento alguien lo calculó de cierta manera, lo metió en un reporte, y desde entonces vive ahí.

El problema aparece cuando el negocio cambia — se agrega una línea de producto, se modifica un proceso, se integra un sistema nuevo — y nadie actualiza la lógica del indicador. El número sigue saliendo, sigue pareciendo razonable, y puede llevar meses de decisiones equivocadas tomarse cuenta de que ya no mide lo que debería medir.

Dashboards que se rompen sin aviso

Esto es especialmente visible en equipos que ya tienen algún nivel de madurez técnica: construyeron un dashboard en Power BI o en Metabase, está funcionando, y un día deja de funcionar o empieza a mostrar resultados extraños. El motivo suele ser que alguien cambió el nombre de una columna en la base de datos fuente, o modificó la lógica de un proceso ETL, sin saber que había tres reportes dependiendo de eso.

Sin contratos de datos — acuerdos explícitos sobre qué puede cambiar y qué no, y quién avisa a quién cuando algo cambia — cada modificación en producción es una bomba de tiempo.

El reporte que tarda dos semanas

“Necesito saber cuántos pacientes con diagnóstico X tuvimos en el primer trimestre, desglosado por sede.”

Si la respuesta es “dejame ver, tengo que cruzar el HIS con el sistema de facturación y con la planilla que lleva administración”, el problema no es de capacidad técnica. Es de arquitectura de datos: la información existe, pero está fragmentada en silos que no se hablan, y el proceso de integrarla es manual y frágil.

Eso tampoco es gobierno de datos en sentido estricto, pero es una consecuencia directa de su ausencia: cuando no hay una capa de datos integrada y documentada, cada pregunta de negocio requiere trabajo de arqueología.

Por qué pasa esto en empresas medianas

Las grandes corporaciones tienen este problema resuelto (o en proceso de resolverlo) porque tienen equipos dedicados y presupuestos para ello. Las startups chicas todavía no lo tienen porque el volumen de datos no lo justifica.

Las empresas medianas — 50 a 500 personas — están en el peor punto del espectro: ya tienen suficientes sistemas y suficiente volumen de datos como para que el caos sea real, pero no tienen el músculo interno para organizarlo, y el problema creció de forma orgánica sin que nadie lo viera venir.

Nadie decidió tener un mal gobierno de datos. Simplemente nadie decidió tener uno bueno.

El proceso típico es este: se implementa el ERP, se agrega el CRM dos años después, se contrata a alguien que arma reportes en Excel cruzando exports de los dos, esos reportes se convierten en “la fuente oficial”, después llega un analista que los replica en Power BI con lógica ligeramente distinta, y en algún momento hay cuatro versiones del mismo número viviendo en cuatro lugares distintos.

Qué se puede hacer, y en qué orden

La buena noticia es que resolver esto no requiere necesariamente un proyecto de transformación de largo plazo. Hay pasos concretos que se pueden tomar en semanas, no en años.

Paso 1: Identificar los cinco indicadores que más peleas generan

No hay que documentar todo el negocio de una vez. Eso paraliza. Hay que empezar por los indicadores que aparecen en todas las reuniones de directorio y que siempre generan discusión sobre cuál número es el correcto.

Para cada uno de esos cinco indicadores, documentar:

• Definición exacta: qué incluye y qué excluye
• Fuente: de qué sistema viene el dato base
• Proceso de cálculo: qué transformaciones se aplican
• Frecuencia de actualización: con qué cadencia se refresca
• Dueño: quién es responsable de que sea correcto

Eso es un glosario de datos mínimo viable. No requiere software especial — puede vivir en un Google Doc o en Notion. Lo que importa es que exista y que todos sepan dónde está.

Paso 2: Establecer una fuente de verdad por indicador

Una vez documentados los indicadores, hay que definir cuál sistema es la fuente oficial para cada uno. Si “clientes activos” viene del CRM, viene del CRM — y el ERP puede tener su propio número por sus propios motivos, pero no compiten en la misma reunión.

Esto suena obvio, pero requiere una decisión explícita y comunicada. Sin esa decisión, cada área sigue usando el número que le conviene o que conoce mejor.

Paso 3: Auditar los reportes existentes

Con la documentación en mano, revisar los reportes que se usan regularmente y verificar si la lógica que usan coincide con las definiciones acordadas. En la mayoría de los casos, van a aparecer discrepancias — eso es normal y esperado. El objetivo de este paso no es juzgar, es identificar cuáles reportes necesitan ser actualizados para alinearse con la fuente de verdad.

Paso 4: Agregar visibilidad a los cambios en producción

Este es el paso más técnico, pero también el que previene más problemas futuros. Cuando alguien modifica una tabla en la base de datos o cambia la lógica de un proceso ETL, tiene que haber un mecanismo para saber qué reportes dependen de eso.

En entornos más maduros esto se resuelve con herramientas de linaje de datos. En entornos más simples, alcanza con una convención: antes de modificar algo en producción, revisar un registro de dependencias. Si no existe ese registro, el paso previo es crearlo.

Cuándo esto NO es suficiente

Si los datos están completamente fragmentados en silos que no se pueden integrar sin trabajo manual, los pasos anteriores alivian el síntoma pero no resuelven el fondo. En ese caso, la conversación que hay que tener es sobre arquitectura: qué capa de integración se necesita para que los datos de distintos sistemas puedan hablarse de forma confiable.

Eso ya es un proyecto de ingeniería de datos, no de documentación. Pero la documentación sigue siendo el primer paso — porque sin saber qué es lo que se quiere integrar y bajo qué definiciones, cualquier arquitectura que se construya va a reproducir el mismo caos en otra capa.

La señal de que estás en el camino correcto

Cuando alguien en la empresa puede responder “¿cuántos clientes activos tenemos?” en menos de dos minutos, con un número único, y puede explicar exactamente de dónde viene ese número y qué incluye — eso es gobierno de datos funcionando.

No es un estado perfecto. No es la ausencia total de ambigüedad. Es la capacidad de tener conversaciones de negocio sobre el negocio, y no sobre cuál reporte creerle.

Para la mayoría de las empresas medianas, llegar ahí no requiere un proyecto de seis meses. Requiere tres reuniones, un documento compartido, y la voluntad de tomar una decisión sobre cuál sistema manda en qué.

Lo difícil no es técnico. Es organizacional: alguien tiene que tomar esa decisión y sostenerla cuando el área que “pierde” empuje para volver a usar su número.

---

¿Tu empresa tiene este problema pero no sabés por dónde empezar a resolverlo? El Smart Blueprint es un diagnóstico de 10 horas que mapea dónde están los quiebres en tu capa de datos y qué priorizar primero. Precio fijo, sin sorpresas — escribinos acá.

---

Artículos relacionados:

• Tu empresa no tiene un problema de IA. Tiene un problema de datos.
• Tu ERP ahora tiene IA: lo que el proveedor no te cuenta antes de activarla