El JOIN que inventó un proveedor

Durante unos días tuvimos escrito, en un documento que iba a presentarse a la dirección de una empresa, este hallazgo:

«Su principal proveedor concentra el 46% de sus compras: alrededor de $415 millones de pesos. Una dependencia de ese tamaño es un riesgo de continuidad que conviene atender.»

La frase tenía todo lo que se le pide a un buen hallazgo. Era específica, era grave, era accionable y encajaba con lo que cualquiera espera de un distribuidor: que compre mucho de pocos.

Era falsa. Ese proveedor les vendía, en realidad, cerca de un millón de pesos al año.

La detectamos en verificación interna, antes de presentarla. Este artículo trata de por qué estuvo a punto de pasar, porque el mecanismo que la produjo no tiene nada de exótico: es la forma más común en que un análisis correcto en apariencia sale mal.

Dónde nace el error#

Aspel SAE guarda sus documentos en tablas separadas por tipo y las nombra por convención: un prefijo para el lado de ventas, otro para compras, y dentro de cada familia una letra que indica de qué documento se trata.

El problema es que las letras no significan lo mismo en las dos familias. En la de ventas, cierta letra corresponde a cotizaciones. En la de compras, esa misma letra corresponde a facturas. Dos tablas con nombres casi idénticos, contenidos que no se parecen y una diferencia de un solo carácter que no perdona.

Leímos una tabla de la familia de ventas como si fuera de compras. Un carácter de diferencia en el nombre, y la consulta corrió sin un solo error. Lo que en realidad teníamos enfrente eran cotizaciones: ofertas emitidas, no dinero gastado.

Eso, por sí solo, ya bastaba para inflar todo. Una empresa cotiza muchísimo más de lo que vende, y bastante más de lo que compra. El universo de cotizaciones de esta operación superaba los dos mil millones de pesos, contra unos noventa y cuatro millones de compras reales en el mismo periodo. Estábamos midiendo intenciones y llamándolas gastos.

La segunda mitad: la llave que sí embonó#

El error de tabla, solo, habría dado cifras grandes pero anónimas. Lo que le dio nombre y apellido fue el segundo paso.

En esa tabla hay una columna con la clave de la contraparte del documento. En la familia de ventas, esa contraparte es el cliente. Nosotros la unimos contra el catálogo de proveedores.

Debería no haber coincidido nada. Coincidió casi todo, por una razón banal: los dos catálogos usan claves numéricas cortas. Existe el cliente 47 y existe el proveedor 47. Son entidades distintas, sin relación alguna, y comparten identificador porque cada catálogo numera desde uno por su cuenta.

El resultado fue un reporte impecable en su forma: nombres de proveedores reales, montos reales, porcentajes que sumaban cien. Cada renglón era una mentira compuesta de dos verdades — el nombre de un proveedor auténtico pegado al monto cotizado a un cliente que no tenía nada que ver con él.

Por qué sobrevivió a la primera lectura#

Aquí está la parte que importa, y no es técnica.

El error que sobrevive no es el absurdo: es el verosímil.

Si aquel cruce hubiera arrojado que un proveedor concentra el 4,600% de las compras, se habría detectado en dos segundos. Arrojó 46%, que es exactamente la clase de número que uno espera encontrar. Los distribuidores concentran compras. Las concentraciones de 40 a 60% en un proveedor principal son comunes y son, con razón, motivo de preocupación.

O sea que el número falso confirmaba lo que ya creíamos saber del negocio. Y una cifra que confirma se revisa menos que una que sorprende. Ese es el sesgo que hay que administrar: no revisamos con la misma dureza lo que nos da la razón.

Un dato falso y verosímil es más peligroso que no tener el dato, por la misma razón por la que un reloj intermitente es peor que ningún reloj: se le sigue creyendo.

Cómo se cayó#

No se cayó revisando la consulta. Se cayó comparando contra algo que la consulta no podía tocar.

La empresa vende alrededor de $80 millones al año. El hallazgo afirmaba que le compraba $415 millones a un solo proveedor.

Nadie compra cinco veces lo que vende. No hay modelo de negocio, ni acumulación de inventario, ni estrategia de importación que lo sostenga. En el momento en que se pusieron los dos números en la misma frase, el hallazgo se desarmó solo — y con él, todo lo que había salido del mismo camino.

Ese es el control que más rinde y el que más se omite: antes de creerle a una cifra grande, hay que buscarle un techo independiente. Un número que provenga de otra fuente, calculado por otro camino, que acote lo que el primero puede valer como máximo. Las ventas anuales acotan las compras. La nómina acota la plantilla. La capacidad instalada acota la producción. Ninguna de esas comparaciones requiere saber SQL, y cualquiera de ellas habría bastado.

El otro tipo de trampa, que es el opuesto#

En la misma base convive una trampa de la familia contraria, y ponerlas lado a lado explica cuál de las dos hay que temer.

El campo que identifica cada documento viene con diez espacios en blanco a la izquierda. Es un resabio de cómo se diseñó el sistema hace décadas. Cualquier cruce que use ese campo sin limpiarlo antes devuelve cero resultados.

Cero. Ninguno. Un reporte vacío.

Esa trampa cuesta una tarde de frustración y no produce una sola conclusión equivocada, porque un resultado vacío es imposible de malinterpretar: nadie presenta una tabla en blanco. La primera trampa, en cambio, cuesta una reunión con la dirección y una decisión tomada al revés.

De ahí sale una preferencia de diseño que aplicamos desde entonces en todo lo que construimos: entre un sistema que falla ruidosamente y uno que entrega algo dudoso en silencio, siempre el primero. Un proceso que se detiene y grita se arregla. Un proceso que sigue caminando con el dato equivocado se descubre meses después, cuando ya se decidió sobre él.

Lo que nos quedó como regla#

Dos, y las dos son de método, no de herramienta:

Antes de cruzar dos tablas, verificar qué es cada una. No por su nombre: por su contenido. Contar los registros, mirar diez renglones, sumar los montos y preguntarse si esa suma tiene sentido para el tamaño de la empresa. Un nombre de tabla es una etiqueta que alguien escribió hace veinte años; el contenido es el hecho.

Y no presentar ninguna cifra grande sin un techo independiente. Si no hay contra qué acotarla, no está lista para una reunión, por buena que se vea la consulta que la produjo.

Publicamos esto porque el valor de un análisis no está en que nunca falle: está en que el error se detenga antes de salir.

Qué hicimos#

Contrastar contra algo que no controlamos. Antes de que cualquier cifra salga en una lámina, se cruza contra una fuente independiente: el estado financiero del despacho, el estado de cuenta del banco, o un conteo físico. Si las dos no se parecen, no sale.

En este caso bastó una pregunta de treinta segundos —¿cuánto le compramos a ese proveedor al mes?— para que $415 millones se desplomaran a un millón al año. Nadie que conozca el negocio se traga una cifra así; el problema es que el análisis llega antes que quien conoce el negocio.

Y el nombre de la tabla se lee dos veces. Cuando dos familias de tablas difieren en un carácter y usan las mismas letras para cosas distintas, la consulta corre sin error y devuelve basura con forma de dato. Lo que separa una revisión seria de una presentación bonita no es el talento — es el paso aburrido de verificar contra algo que uno no controla.

Este caso proviene de trabajo real sobre la base de datos de un distribuidor industrial de refacciones importadas. Las cifras están redondeadas y todo dato que permitiera identificar a la empresa, a sus proveedores o a sus clientes fue removido. El hallazgo erróneo fue detectado en verificación interna y nunca llegó a presentarse al cliente.