En el comité, comercial presenta las ventas del trimestre. Financiera trae su propio número. Difieren en un cuatro por ciento.
Los dos partieron del mismo archivo del ERP. Ninguno se equivocó.
Los dos números están bien
Esto es lo que hace que la discusión no se resuelva mirando el archivo.
Comercial excluyó las devoluciones porque para medir gestión comercial le interesa lo vendido. Financiera las restó porque para el estado de resultados lo que importa es lo facturado neto. Los dos criterios son razonables y ninguno está escrito en ninguna parte.
Multiplique eso por las decisiones que se toman en cada limpieza —qué filas excluir, cómo tratar los registros incompletos, si el pedido cancelado del día 30 cuenta o no— y ya tiene la explicación completa de por qué las cifras de una empresa no cuadran entre áreas.
No hay un error que encontrar. Hay dos criterios que nunca se compararon porque nunca se escribieron.
Reglas técnicas y reglas de negocio
Conviene separarlas, porque se gobiernan distinto.
Las reglas técnicas arreglan la forma del dato sin decidir nada de negocio: quitar espacios sobrantes, llevar las fechas a un formato único, convertir a número lo que llegó como texto, unificar la escritura de una ciudad. Nadie va a discutir si Bogotá y BOGOTA son la misma ciudad. Se pueden automatizar sin consultar a nadie.
Las reglas de negocio deciden qué cuenta: si una devolución resta de la venta, si un pedido cancelado entra al total, desde qué monto un cliente es mayorista. Estas sí exigen una decisión de la empresa, y son exactamente las que hoy viven en la cabeza de alguien.
El error habitual no es aplicar mal las reglas. Es tratar las de negocio como si fueran técnicas: resolverlas sobre la marcha, en silencio, cada mes.
El orden importa más de lo que parece
Aquí hay algo poco intuitivo: las mismas reglas, en distinto orden, dan resultados distintos.
Tres ejemplos que ocurren todos los días:
- Deduplicar antes de normalizar no encuentra casi nada.
Comercial Andes S.A.S.yCOMERCIAL ANDES SASson la misma empresa, pero mientras estén escritas distinto el sistema las ve como dos. De ahí sale la queja de que «la deduplicación no sirvió». - Rellenar vacíos antes de deduplicar calcula el promedio sobre filas repetidas y lo desplaza. El hueco se llena con un número que no corresponde.
- Validar antes de normalizar marca como inválido lo que solo estaba mal escrito: un teléfono con guiones, un documento con puntos.
Por eso la reproducibilidad no depende solo de tener las reglas escritas. Depende de que el orden de ejecución sea fijo y no lo decida quien configura.
En Lorian Analytics el motor tiene un orden canónico de seis fases, y las ejecuta siempre así:
| Fase | Qué resuelve |
|---|---|
| 1 · Estructura | quita columnas y filas vacías: se trabaja sobre una tabla ya ordenada |
| 2 · Normalización | textos, números, monedas, fechas y booleanos a un formato consistente |
| 3 · Reglas globales | con los valores ya comparables: unificar variantes y eliminar duplicados |
| 4 · Valores faltantes | se rellena después de deduplicar, para no promediar sobre repetidos |
| 5 · Derivados y validación | columnas calculadas, extracciones y validaciones sobre datos ya limpios |
| 6 · Salida | nombres, orden de columnas y ofuscación de lo sensible |
No importa en qué orden se configuren las reglas: el motor las corre en esta secuencia. Esa es la razón de que dos ejecuciones den exactamente lo mismo, y no la buena memoria de quien las configuró.
De sesión de trabajo a objeto que se puede leer
Mientras la limpieza sea una sesión —abrir el archivo, hacer los pasos, guardar— el conocimiento de cómo se produce esa cifra pertenece a la persona, no a la empresa. Documentarla en un instructivo ayuda poco: los instructivos envejecen y nadie los abre.
El cambio real es cuando las reglas dejan de ser una secuencia de acciones y se vuelven un objeto propio: una receta que se guarda, se lee, se vuelve a aplicar y queda registrada cuando alguien la ejecuta.
Tres cosas cambian de inmediato:
- Se puede comparar. Comercial y financiera pueden poner sus dos recetas lado a lado y ver exactamente en qué difieren. La discusión pasa de «tu número está mal» a «tú excluyes devoluciones y yo no» — que se resuelve en un minuto.
- Se puede repetir. El archivo del mes siguiente entra por el mismo camino, sin que nadie recuerde nada.
- Se puede delegar sin delegar el criterio. Una receta puede compartirse para que alguien la ejecute sin poder editarla. El analista corre la limpieza del cierre; el criterio sigue siendo de quien lo definió.
Ese tercer punto es el que más se subestima. La alternativa habitual es binaria: o la persona hace el trabajo, o entrega el archivo y que cada quien limpie como pueda. Poder separar ejecutar de cambiar el criterio es lo que permite que el proceso escale sin fragmentarse.
El catálogo no es el producto: el criterio sí
Vale una aclaración, porque es fácil confundirse: tener muchas transformaciones disponibles no resuelve nada por sí solo. Excel también las tiene.
Lo que resuelve el problema es que la combinación concreta que su empresa eligió quede declarada — que se sepa que las ventas se limpian con estas reglas, en este orden, y que eso sea verificable por cualquiera. Las 34 reglas del catálogo son el vocabulario; la receta es la frase, y es la frase la que se puede defender en un comité.
Lo que cambia
La próxima vez que dos áreas lleguen a cifras distintas, la conversación no empieza buscando el error. Empieza abriendo las dos recetas.
Y en la mayoría de los casos termina rápido, con una conclusión que hoy toma semanas: no había un error, había dos definiciones. Elegir cuál es la de la empresa es una decisión de negocio de cinco minutos — siempre que las dos estén escritas.
En Lorian Analytics las reglas se guardan como recetas reutilizables, el motor las ejecuta en un orden canónico de seis fases y cada aplicación queda en el registro de auditoría. Puede ver las 34 transformaciones del catálogo, cómo funcionan las recetas, o seguir con quién puede consumir el dato, la última de las seis preguntas.