Data lineage para mortales: ¿de dónde salió este número?

Hay una pregunta capaz de congelar cualquier comité de gerencia. No es agresiva, no es técnica, y casi siempre la hace la persona con menos contexto y más poder de la sala:

“¿Y este número de dónde salió?”

Silencio. El gerente que presenta mira la lámina. La lámina dice “margen operacional obra: 23%”. El número lo mandó control de gestión, que lo sacó de una planilla, que se alimenta de un export del ERP, que alguien filtró con criterios que no están escritos en ninguna parte, en una fecha que nadie recuerda. La respuesta honesta sería: “no lo sé con certeza”. La respuesta real es: “lo vemos y te confirmamos”.

Multiplica esa escena por cada KPI de cada lámina de cada comité, y tienes el estado real de la trazabilidad de datos en la mayoría de las empresas: números con autoridad de hecho y genealogía desconocida.

El nombre técnico y por qué te lo venden caro

Esto tiene nombre en la industria: data lineage, el rastro completo de un dato desde su origen hasta su presentación, incluyendo cada transformación intermedia. Y como tiene nombre en inglés, tiene también un mercado de plataformas enterprise que lo resuelven con catálogos automáticos, grafos interactivos y una licencia anual que cuesta lo que varios sueldos.

Esas herramientas tienen sentido cuando tienes cientos de pipelines y decenas de analistas. Pero la versión que necesita una empresa mediana no es un grafo interactivo: es poder responder cinco preguntas sobre cada número que llega a un comité:

1. ¿De qué fuente sale? (sistema, tabla, export, planilla)
2. ¿Qué transformaciones sufre en el camino? (filtros, exclusiones, ajustes manuales)
3. ¿Cuándo y con qué corte se calcula? (mensual al día 5 hábil no es lo mismo que mensual al día 10)
4. ¿Quién responde por la definición? (una persona con nombre, no un área: responde por lo que dice la ficha, no manda sobre cómo miden los demás)
5. ¿Cuándo cambió por última vez la regla de cálculo?

Si esas cinco respuestas existen y están escritas, tienes la genealogía del número. El software es opcional; la disciplina no. Lo que no es opcional, y a eso vuelvo más abajo, es mantener la respuesta pegada al cálculo real: una ficha que envejece sin avisar hace más daño que no tener ficha.

Las tres formas en que la genealogía se rompe

En mi experiencia, el rastro de un KPI se pierde casi siempre de una de estas tres maneras: una ocurre en el recorrido del dato, las otras dos en las reglas que lo definen.

1. El eslabón manual invisible

El pipeline es: ERP → export → “la planilla de Marcela” → lámina. Ese tercer eslabón concentra casi toda la lógica de negocio real: qué centros de costo se excluyen, cómo se tratan los adicionales, qué ajuste se le hace “siempre” a la línea de remuneraciones. Todo eso vive en fórmulas sin comentario y en la memoria de Marcela. El día que Marcela sale de vacaciones, el KPI corporativo entra en modo fe.

2. La definición bifurcada

“Margen” para operaciones excluye gastos generales de oficina central; para finanzas los incluye. Ambos números son correctos según su propia definición, ambos se llaman igual, y cada cierto tiempo aterrizan en la misma mesa con valores distintos. La reunión que sigue no produce gestión: produce arqueología. Es el problema de las entidades sin dueño, en su versión de indicadores.

La tentación es zanjarlo nombrando a un dueño único del “margen”, y no resuelve nada: la diferencia es legítima, cada área necesita su número para decidir lo que le toca decidir, y un dueño único solo traslada la discusión técnica a una pelea por quién manda. La salida es la contraria y es aburrida: aceptar que son dos indicadores distintos y obligarlos a llamarse distinto.

3. El cambio de regla sin fecha

El KPI mejoró en abril. ¿Mejoró la operación, o alguien cambió la fórmula, amplió una exclusión, corrigió un error histórico? Si las reglas de cálculo no tienen historial de cambios, toda serie de tiempo es sospechosa exactamente en sus puntos más interesantes: los quiebres.

La solución artesanal: el diccionario de indicadores versionado

Lo que ha funcionado en las implementaciones que he hecho es humilde: un diccionario de indicadores en texto plano, versionado en Git. Un archivo por KPI:

1
# margen-operacional-obra
2

3
**Dueño:** Jefa de Control de Gestión
4
**Fuente:** ERP, tablas `ventas_ep` y `costos_directos`
5
**Frecuencia:** mensual, cierre día 5 hábil
6

7
## Regla de cálculo
8
(ingresos por EP aprobados − costos directos imputados) / ingresos por EP aprobados
9

10
## Exclusiones y decisiones
11
- Excluye adicionales sin orden de cambio aprobada (decisión CG 2024-03)
12
- Gastos generales de oficina central NO incluidos (ver `margen-consolidado`
13
  para la versión que los incluye)
14
- Obras en período de garantía: excluidas desde 2025-06
15

16
## Consulta canónica
17
Ver `sql/margen_operacional_obra.sql` en este repositorio

¿Por qué en Git y no en una wiki? El argumento fácil sería decir que la wiki no deja rastro, pero es falso: Confluence, Notion y SharePoint guardan historial con autor y fecha. Las razones buenas son las mismas que ya escribí para la documentación en general, más tres específicas de indicadores:

• La ficha viaja junto al cálculo. Una sola confirmación cambia la regla escrita y la consulta que la implementa. En una wiki, la definición y el código viven en sistemas distintos y se desincronizan por construcción, no por descuido.
• El cambio pasa por revisión antes de entrar. Modificar la definición de un KPI corporativo debería requerir que otra persona lo apruebe. En una wiki, quien tiene permiso edita y guarda, y el aviso llega después, si llega.
• El historial no lo administra quien tiene incentivo a reescribirlo. El repositorio vive fuera de la herramienta que controla el área dueña del número.

Por encima de las tres: el historial de cambios de la definición es parte de la definición. Cuando el margen “mejora” en abril, git log del archivo responde en diez segundos si cambió la realidad o cambió la regla.

La fecha del cambio no basta: la serie queda empalmada

Saber que la regla cambió en abril es la mitad de la respuesta. La otra mitad decide si la serie sirve: ¿se recalculó la historia completa con la regla nueva, o se pegó la definición nueva sobre los meses viejos y nadie lo dijo? En el segundo caso tienes un gráfico de tendencia que compara dos cosas distintas, que es justamente lo que el comité cree que no está haciendo.

Por eso la ficha necesita versiones fechadas, no solo la regla vigente:

1
## Historial de reglas
2
- **v3 (desde 2025-06):** excluye obras en período de garantía.
3
  Serie NO recalculada: los meses anteriores a 2025-06 siguen bajo v2.
4
- **v2 (2024-03 a 2025-05):** excluye adicionales sin orden de cambio aprobada.
5
  Serie recalculada hacia atrás hasta 2023-01.
6
- **v1 (hasta 2024-02):** definición original.

Dos líneas por versión, y cualquier serie de tiempo deja de ser una trampa. Con esto, el salto de la curva en junio se lee correctamente: no es que la operación mejorara, es que dejamos de contar las obras en garantía y no arreglamos la historia. Sin esto, esa mejora entra a la presentación como logro de gestión y alguien la celebra.

Documentar no es trazar, y confundirlos sale caro

Aquí conviene frenar, porque es donde este tipo de proyecto se engaña a sí mismo.

Una ficha escrita a mano es una declaración sobre el cálculo, no el cálculo. Las dos cosas pueden divergir en silencio: alguien amplía un filtro en la planilla, no toca el archivo, y la ficha sigue diciendo lo que decía el año pasado. El lineage de las plataformas caras se deriva del código que computa, y por eso no puede mentir. Esa, y no el grafo interactivo, es su ventaja real.

Importa porque una ficha vencida es peor que ninguna ficha: produce confianza falsa. Sin diccionario, el gerente al menos sabe que no sabe. Con un diccionario desactualizado, cree que sabe, y git log le responde con autoridad sobre una regla que ya nadie aplica.

Por eso la trazabilidad artesanal vive en dos regímenes distintos, y vale la pena no mezclarlos:

• Cálculo en código versionado. La consulta SQL está en el mismo repositorio que la ficha, y una sola confirmación cambia la regla escrita y la regla ejecutada. La documentación no puede desactualizarse respecto de sí misma: la trazabilidad es real y se verifica sola.
• Cálculo en planilla. La ficha es una declaración con fecha de vencimiento. Sirve, y es infinitamente mejor que nada, pero exige un ritual explícito: cada cierto tiempo alguien abre la planilla y confirma que sigue haciendo lo que la ficha dice. Sin ese contraste, la ficha envejece sin avisar.

Lo escribo desde adentro: en la constructora donde trabajo estoy construyendo el ERP que usamos, y ahí las reglas de los indicadores viven en el código que las calcula, no en una planilla intermedia. Aclaro lo obvio para que no se lea como receta: nadie necesita construir un ERP para tener trazabilidad. Ese es el extremo caro del primer régimen, y lo que se gana ahí se consigue igual con una consulta SQL versionada y un archivo de texto al lado.

Y de ahí sale la parte incómoda del método, que prefiero decir antes de que la descubras en la semana cuatro: el diccionario no elimina el eslabón manual invisible, lo hace visible. Si el grueso de la lógica sigue viviendo en la planilla de Marcela, la ficha describe una caja negra desde afuera: con precisión, pero sin garantía.

El diccionario no es el final del trabajo: es el inventario que te dice cuánto trabajo queda. El trabajo real es mover indicadores del segundo régimen al primero, uno a uno, empezando por los que más duelen. Eso es una migración, no una tarde de documentación, y hay que presupuestarla como tal. Cada fórmula que sale de la planilla y entra al repositorio es un tramo de genealogía que deja de depender de una memoria humana; el resto sigue dependiendo de que Marcela conteste el teléfono.

La prueba del que no lo construyó

Para saber cuánto trabajo queda hay una prueba barata. Así se ve en la práctica: la lámina dice “margen operacional obra: 23%”. Le pasas a un analista de otra área la ficha del indicador y el acceso al ERP, y le pides que llegue solo al 23%. No puede preguntarle a nadie: cada vez que se atasca, anota la pregunta y sigue con el supuesto que le parezca.

Vuelve con esto:

• “‘EP aprobados’: ¿aprobados por el mandante o visados internamente? Las fechas no coinciden.”
• “La ficha excluye obras en garantía. ¿De dónde saco cuáles están en garantía? No encuentro el campo.”
• “Me da 24,1%.”

Esas tres líneas son el resultado de la prueba, no el 23%. La primera es una definición ambigua, la segunda es un dato que no está en el sistema, y la tercera es el ajuste que Marcela aplica todos los meses y que no está escrito en ninguna parte. La prueba no es una nota, es un inventario: cada pregunta es una línea de lo que falta migrar, y el orden en que aparecieron es la prioridad.

Por dónde empezar (no por donde crees)

El error clásico es lanzarse a documentar los 200 indicadores del catálogo corporativo. Muere en la semana tres, como todo proyecto de documentación total. El orden correcto es por riesgo:

1. Los 10 números que ve el directorio. Si uno de esos está mal, el costo es máximo. Empieza ahí; en los casos que me ha tocado toma un par de semanas y las sorpresas aparecen de inmediato (mi favorita histórica: dos “ventas del mes” con tres puntos porcentuales de diferencia crónica, ambas oficiales).
2. Los números que pagan bonos. Todo KPI con incentivos asociados necesita definición escrita, dueño y historial, por higiene y por defensa legal. Sin excepción.
3. Los números que cruzan fronteras de área. Ahí viven las definiciones bifurcadas: cada indicador que operaciones y finanzas miran juntos necesita una sola genealogía o una bifurcación explícita y nombrada (margen-operacional-obra vs margen-consolidado, no “margen” dos veces).

El resto del catálogo puede esperar. Un diccionario de 15 indicadores confiables vale más que uno de 200 a medio mantener, por la misma razón que un dashboard vacío vale más que uno decorativo: la señal está en lo que puedes defender, no en lo que puedes listar.

La compuerta, o esto muere en la semana tres igual que el resto

Hay que decirlo con todas sus letras: lo que acabo de proponer es un proyecto de documentación, y los proyectos de documentación mueren por exactamente la misma razón por la que se rompieron los tres eslabones. Nadie mantiene la ficha cuando aprieta el cierre. Prescribir disciplina para curar una falla de disciplina no funciona si no cambias las condiciones.

Lo que sostiene un diccionario en el tiempo no es la buena voluntad ni el recordatorio trimestral: es una regla incómoda, barata y verificable.

• Un número sin ficha no entra a la lámina del comité. Es la única que de verdad importa; las otras dos son ayudas. Duele dos meses, genera una pelea, y después nadie recuerda cómo se trabajaba antes.
• Quien responde por la definición es quien la presenta. Si el gerente expone un número cuya regla no puede explicar, el vacío aparece en la sala y no en un archivo que nadie abre.
• La ficha se revisa dentro del checklist de cierre mensual, no en una instancia aparte. Cinco minutos por indicador, junto al resto del cierre. Toda revisión que necesita su propia reunión ya está muerta.

Sin una compuerta así, el diccionario se escribe en marzo, se cita en mayo y está mintiendo en agosto.