Valiax · Definiciones de métricas y revisión

Dos equipos, una métrica: cómo revisar la definición de ingresos

Una conversación útil empieza por las reglas, sus fuentes y los cambios que todavía necesitan una decisión del negocio.

Thilo Wilts · Valiax · desarrollo de software
30 de octubre de 2026 · Versión 1.1

Dos equipos pueden utilizar la palabra «ingresos» y referirse a cosas distintas. Uno incluye únicamente operaciones completadas; otro incorpora también operaciones liquidadas. Ambos pueden tener una consulta SQL y una explicación razonable. La diferencia no se resuelve eligiendo el número que parece más convincente: primero hay que entender qué representa cada definición.

Para un equipo de BI y para la persona que responde por la métrica en Finanzas o Control de Gestión, compartir esa explicación es una tarea concreta. Este artículo propone revisar una definición pequeña, vincular sus reglas con el código y conservar las preguntas que el código no puede responder. No describe una norma contable ni determina qué debe considerar ingreso una empresa.

1. Poner nombre a la decisión

Antes de explicar una consulta, conviene precisar la pregunta del negocio. ¿Qué operaciones deben entrar? ¿Qué momento se utiliza para asignarlas a un período? ¿Cómo se tratan devoluciones, impuestos o monedas? Un nombre de columna no proporciona esas respuestas por sí solo.

El primer paso puede ser una frase que la persona responsable esté dispuesta a revisar: «Esta definición suma el importe neto de las operaciones cuyo estado se considera incluido». La frase deja dos asuntos distintos a la vista: lo que hace la consulta y la decisión de qué estados deberían incluirse.

También delimita el trabajo. Revisar una definición no demuestra que el sistema de origen tenga todos los registros correctos. Explicar un filtro no equivale a aprobar la política del negocio.

2. Conectar la explicación con su fuente

Un ejemplo completamente ficticio ayuda a observar la diferencia. La primera versión de una consulta contiene:

SELECT SUM(net_amount) AS revenue
FROM sales
WHERE status = 'completed';

Sin ejecutar la consulta ni utilizar datos empresariales, podemos identificar una agregación, una columna y un filtro. Una explicación comprobable sería: «Suma net_amount en las filas de sales cuyo status es completed». Esa frase debe conservar su relación con el fragmento que la respalda.

Todavía no sabemos si net_amount descuenta devoluciones o si todas las filas usan la misma moneda. Esas preguntas necesitan información del negocio o de otras definiciones. Inventar una respuesta a partir de un nombre legible convertiría una interpretación en una certeza injustificada.

Si la definición incorpora un join, aparece otra revisión importante: cómo se relacionan las tablas y si esa relación puede multiplicar filas. Ver una unión en un mapa de dependencias no demuestra que su cardinalidad sea adecuada. La persona técnica debe explicar la relación y la responsable de la métrica debe confirmar su sentido.

3. Comparar cambios sin perder el contexto

En la segunda versión del ejemplo, el filtro pasa a ser:

WHERE status IN ('completed', 'settled');

El cambio amplía los estados incluidos. No demuestra que el importe aumente: no hemos consultado datos ni calculado resultados. Tampoco demuestra que la nueva definición sea mejor. Permite formular una pregunta precisa: ¿el negocio quiere incorporar settled y desde cuándo?

Conservar ambas versiones permite revisar la modificación en su contexto. Es útil identificar el archivo, la versión analizada y la explicación que corresponde a cada una. Si después cambia el código, una aprobación anterior no debería parecer una revisión del nuevo contenido.

Un comentario como «revisado» aporta poco si no queda claro qué regla se examinó. Una observación vinculada al filtro puede explicar qué se aceptó, qué se cuestionó y qué información sigue pendiente.

4. Hacer visibles los límites de la interpretación

Una definición puede contener una función propia, una transformación compleja o una dependencia que falta. En esos casos, la explicación necesita conservar el límite: qué parte se reconoce y qué parte no se ha podido resolver. Una descripción fluida no sustituye la evidencia.

La revisión humana también tiene un alcance. Una confirmación del negocio no convierte automáticamente una operación no interpretada en una operación técnicamente explicada. Conviene mantener separadas la extracción de reglas, las preguntas abiertas y las decisiones de las personas responsables.

Para evaluar una herramienta, este punto merece una prueba específica: introducir una construcción no soportada y comprobar su tratamiento real. Si la limitación no se presenta de forma comprensible, debe registrarse como un problema del ensayo, en lugar de omitirla de la demostración.

5. Probar una revisión pequeña antes de ampliarla

La propuesta de piloto de Verivium, software de Valiax, parte de una definición SQL y dos versiones. Su objetivo es revisar cómo se explican las reglas y cómo se relacionan con fuentes, versiones y observaciones del negocio. El primer ejercicio utiliza únicamente material sintético, sin conexión a una base de datos de producción.

El alcance propuesto es PostgreSQL y expresiones concretas que se hayan comprobado. No promete interpretar cualquier archivo SQL, dbt o Excel. En un entorno local hemos comprobado un caso sintético con dos versiones, fuentes y revisiones. El inicio con un participante requiere además acordar el alcance y aceptar su entorno y caso concretos. Los ejemplos SQL de este artículo son material didáctico; no constituyen una captura ni un resultado de ejecución de Verivium.

Para comparar el trabajo habitual con el ensayo, ambas personas pueden responder las mismas preguntas: ¿qué incluye la definición?, ¿qué fragmento respalda la explicación?, ¿qué cambió?, ¿qué no se puede concluir? Conviene registrar respuestas correctas, dudas, tiempo y ayuda recibida. Repetir un ejercicio puede producir aprendizaje; ese efecto debe anotarse, no presentarse como ahorro atribuible al software.

El primer piloto es gratuito y dura dos semanas, con dos sesiones de trabajo acompañadas y una evaluación final. A cambio, se acuerdan la participación comprometida en las tareas y comentarios honestos y estructurados. No se exige una opinión positiva ni una referencia pública. El alcance incluye apoyo para instalar una instancia local propia en la organización participante y corregir errores dentro del piloto; funciones adicionales o una continuación se acordarían por separado, sin renovación de pago automática. Las fechas y el inicio con un participante concreto siguen sujetos a la aceptación técnica y funcional y al acuerdo correspondiente.

La primera meta es una conversación más precisa sobre una definición realista. Los resultados de un solo ensayo no permiten prometer retorno de inversión ni corrección universal.

¿Qué regla de una métrica cuesta más explicar entre su equipo de datos y el área que la utiliza? Si le interesa explorar un piloto de Verivium, puede conocer Verivium en la web de Valiax o escribir a info@valiax.eu. Para una primera conversación no es necesario compartir archivos de su empresa.