Lo que los datos de mala calidad le cuestan realmente a tu negocio — y por qué detectarlos pronto sale más barato

Una guía no técnica sobre el coste para el negocio de una mala calidad de datos — dónde va realmente el dinero, por qué un error se vuelve unas diez veces más caro en cada etapa que sobrevive y cómo calcular tu propia cifra en lugar de tomar prestada la de un analista.

· 10 min read

Los datos de mala calidad cuestan dinero en cuatro sitios: las horas que tu equipo dedica a arreglarlos, las decisiones que se toman mal por su culpa, la confianza que destruyen en unos informes que ya no se cree nadie, y los clientes y reguladores que los ven antes que tú. Lo importante no es el total, sino la forma. Un error detectado en el punto de entrada cuesta unos minutos. Ese mismo error detectado en un dossier para el consejo cuesta una reunión, una rectificación y una parte de tu credibilidad. Detectarlo pronto no es una preferencia técnica: es toda la economía del problema.

La cifra que probablemente ya has visto

Gartner ha estimado el coste medio de una mala calidad de datos en torno a 12,9 millones de dólares por organización y año. Encontrarás esa cifra en la presentación de cualquier proveedor de calidad de datos, incluida, ya que estamos, esta.

Trátala como punto de partida para una conversación, no como prueba. Es una media entre organizaciones tremendamente distintas, tiene ya varios años, y ningún director financiero ha aprobado jamás un presupuesto porque una consultora publicara una media. La cifra que de verdad va a mover a tu dirección financiera es la que calcules con tus propios últimos seis meses, y esa cifra suele ser más fácil de producir de lo que la gente espera.

La parte más útil de la investigación no es el total. Es el hallazgo constante de que el coste de un error escala con el tiempo que sobrevive.

La regla 1-10-100

La regla empírica más usada en gestión de la calidad dice que los costes escalan aproximadamente un orden de magnitud en cada etapa:

Los multiplicadores exactos no son lo importante y nunca pretendieron ser precisos. Lo importante es la forma, y esa aguanta frente a la experiencia de casi cualquiera: arreglar un registro de cliente duplicado en el punto de entrada es un gesto trivial, y desenredar seis meses de atribución de ingresos duplicada en tres sistemas aguas abajo es un proyecto.

Por eso merece la pena decir en voz alta “detéctalo pronto”. Suena a perogrullada. En realidad es una afirmación sobre una diferencia de coste de cien veces.

Dónde va realmente el dinero

Cuatro bolsas, más o menos por orden de visibilidad:

CosteQué aspecto tienePor qué pasa desapercibido
RetrabajoAnalistas conciliando dos cifras que deberían coincidir; ingenieros relanzando pipelines; una “semana de calidad de datos” cada trimestreEnterrado en los salarios, nunca desglosado
Decisiones equivocadasStock pedido contra una previsión rota; una campaña dirigida a una lista mal segmentada; una contratación hecha contra un pipeline infladoSe atribuye al mal criterio, no a la mala entrada
Pérdida de confianzaEquipos que se montan hojas de cálculo privadas porque no se creen el dashboardParece cultura, cuesta como infraestructura duplicada
Fallo externoFacturas equivocadas, declaraciones regulatorias equivocadas, un cliente al que se le dice algo falso sobre su propia cuentaSolo se contabiliza cuando se convierte en incidente

La primera bolsa es la que todo el mundo nota y nadie mide. Si tus analistas dedican un día a la semana a conciliar cifras, eso es aproximadamente un 20 % de tu capacidad analítica gastada en demostrar que los datos de ayer estaban bien: un coste que no aparece en ninguna partida y que podrías cuantificar esta misma tarde.

La cuarta bolsa es la que acaba en una reunión del consejo. Y es también la que la detección temprana elimina casi por completo, porque los fallos externos rara vez los provocan problemas exóticos. Los provocan problemas corrientes que nadie estaba vigilando.

Por qué los errores se encarecen cuanto más viajan

Un error en una tabla de origen es un hecho sobre una tabla. Cuando ha pasado por tu capa de transformación, es un hecho sobre todos los modelos construidos sobre esa tabla. Cuando llega a un dashboard, es un hecho sobre todas las decisiones que alguien tomó mientras lo miraba.

Tres cosas se acumulan:

El radio de impacto crece. Una columna defectuosa alimenta cinco modelos, que alimentan veinte dashboards. Arreglar la columna es fácil; encontrar a los veinte consumidores, avisarles y corregir lo que ya hicieron, no.

Las pruebas desaparecen. Un duplicado detectado el mismo día en que aterriza puede rastrearse hasta la carga que lo causó. Ese mismo duplicado encontrado en una revisión trimestral hay que reconstruirlo a partir de logs que quizá ya hayan rotado, y lo hace alguien que no estaba allí.

La confianza no se recupera a la misma velocidad a la que se pierde. Un solo informe rectificado te gana meses de gente comprobando tus cifras por su cuenta en sus propias hojas de cálculo. Ese coste es real, permanente e invisible en todos los presupuestos que escribas en tu vida.

Calcula tu propia cifra

No necesitas un modelo de madurez ni una consultora. Coge tus últimos seis meses y responde a cinco preguntas:

  1. ¿Cuántos incidentes de datos tuviste? Cuenta cualquier caso en el que alguien tuvo que corregir, relanzar o pedir disculpas por una cifra.
  2. ¿Cuánto tardó cada uno en detectarse? No en arreglarse: en *notarse*. Esta suele ser la pregunta que asusta.
  3. ¿Cuánto tardó cada uno en resolverse, contando a todas las personas implicadas y no solo a quien escribió el arreglo?
  4. ¿Cuántos los encontró un consumidor en lugar de vosotros? Que sea una persona interesada quien encuentre tu error es una categoría distinta y mucho más cara que encontrarlo tú.
  5. ¿Cuánto costó realmente el peor de todos en decisiones tomadas, devoluciones emitidas o declaraciones corregidas?

Multiplica las horas por un coste cargado, suma el peor caso y ya tienes una cifra defendible construida íntegramente con tu propio historial. En la mayoría de los equipos el resultado cae en un punto que deja la conversación sobre herramientas en muy poco tiempo.

La métrica más útil de esa lista es, con diferencia, el tiempo hasta la detección. Es la que más controlas, la que determina en cuál de las casillas 1-10-100 acaba un error, y la que una herramienta de monitorización mueve directamente.

Qué significa “detectarlo pronto” en la práctica

La detección temprana no es una cultura de vigilancia. Es un número reducido de hábitos concretos y aburridos:

Comprueba los datos donde entran, no donde se consumen. La validación va en la frontera —el punto en el que los datos llegan de un sistema de origen o aterrizan desde una carga— porque ahí el radio de impacto sigue teniendo el ancho de una sola tabla.

Pon por escrito qué significa “correcto”, antes de necesitarlo. La mayoría de los incidentes de datos no son exóticos. Son un campo obligatorio que se quedó en nulo, una clave que se duplicó, una columna de estado a la que le creció un valor que nadie esperaba, una tabla que sencillamente no se actualizó. Esas expectativas pueden declararse de antemano, en términos llanos, por la persona que posee los datos, y una vez escritas pueden comprobarse de forma automática, para siempre y sin coste adicional.

Eso es justamente un contrato de datos. Es un acuerdo entre quien produce un dataset y todos los que dependen de él, escrito en un formato que pueden leer tanto una persona como una máquina: estas columnas existen, esta nunca está vacía, esta es única, esta solo contiene estos cinco valores y esta tabla nunca tiene más de un día. Catalyst usa el Open Data Contract Standard exactamente para esto, de modo que el acuerdo vive en un formato abierto y portable en lugar de dentro del producto de un proveedor.

Vigila la frescura, no solo la corrección. El incidente de datos más común no es tener datos equivocados. Es tener datos *ausentes*: una carga que no se ejecutó sin avisar, dejando las cifras de ayer con un aspecto perfectamente válido. Una comprobación de frescura es la regla más barata que escribirás nunca y detecta una proporción desmedida de los incidentes reales.

Alerta del cambio, no del estado. Avisa a la gente cuando algo *empieza* a fallar. Repetir “sigue fallando” cada hora es la forma más rápida de que se silencie un canal, y un canal silenciado es peor que no tener canal, porque parece cobertura.

Dirige la alerta a quien puede arreglarlo. Un fallo de calidad que llega a un canal general es problema de todos y, por tanto, de nadie. Debería llegar al propietario que figura en el contrato.

Cómo defenderlo internamente

Tres enfoques que suelen calar mejor que el coste de los datos de mala calidad en sí:

Empieza por el tiempo hasta la detección, no por la calidad. “Ahora mismo nos enteramos de los problemas de datos cuando nos escribe una persona interesada, de media once días después” es una frase que consigue presupuesto. “Nuestra calidad de datos es mala” es una frase que consigue un asentimiento.

Acótalo a una decisión, no a una plataforma. Elige los tres datasets que hay detrás de tu informe más usado y cúbrelos primero. Nadie aprueba “monitorizarlo todo”. Mucha gente aprueba “asegurar que el dashboard de ingresos no vuelva a estar mal”.

Reporta cobertura, no incidentes. Una vez que la monitorización está en marcha, la cifra que muestra progreso es la proporción de datasets críticos bajo contrato y la tendencia en la rapidez con la que se detectan los fallos. Un número de incidentes a la baja es ambiguo: puede significar que las cosas mejoraron, o puede significar que dejaste de mirar.

Por dónde empezar

  1. Lista tus diez datasets más usados. No todos: aquellos con los que la gente toma decisiones de verdad.
  2. Para cada uno, pregunta a su propietario qué tendría que pasar para que estuviera mal. Te dará cuatro o cinco respuestas, y serán respuestas sencillas.
  3. Escríbelas como un contrato y conviértelas en comprobaciones automáticas.
  4. Ejecuta las comprobaciones con la misma cadencia que los datos, justo después del job que los carga.
  5. Envía los fallos al propietario, y solo en la transición hacia el fallo.

Para la mayoría de los equipos eso es una semana de trabajo, y mueve tu error típico de la casilla de los 100 dólares a la de 1 dólar. Sea cual sea el multiplicador real en tu organización, ahí está el retorno.

Preguntas frecuentes

¿Cuánto le cuesta a una empresa una mala calidad de datos?

Gartner ha estimado una media de unos 12,9 millones de dólares por organización y año, pero las medias de una economía entera no son base para un caso de negocio. Calcula la tuya con los últimos seis meses: cuenta tus incidentes de datos, las horas dedicadas a detectar y resolver cada uno, y el coste del peor. Esa cifra es defendible de una forma en la que un benchmark prestado nunca lo será.

¿Qué es la regla 1-10-100 en calidad de datos?

Una regla empírica de la gestión de la calidad: cuesta aproximadamente 1 dólar prevenir un error, 10 dólares corregirlo una vez que está dentro de tus sistemas y 100 dólares convivir con las consecuencias de haber actuado sobre él. Los multiplicadores nunca pretendieron ser medidas precisas; la idea es que el coste escala bruscamente con el tiempo que un error sobrevive sin detectarse.

¿Por qué detectar los errores de datos pronto sale más barato?

Porque el coste de un error crece con su radio de impacto. Detectado en el origen, afecta a una tabla y puede rastrearse hasta la carga que lo causó. Si se deja estar, se propaga a todos los modelos y dashboards aguas abajo, las pruebas necesarias para diagnosticarlo caducan y la gente toma decisiones basadas en él. La detección temprana es la diferencia entre un arreglo de cinco minutos y una conciliación de varias semanas.

¿Cómo mido el coste de los datos de mala calidad en mi organización?

Mide cuatro cosas: número de incidentes, tiempo hasta la detección, tiempo hasta la resolución y cuántos reportó un consumidor en lugar de encontrarse internamente. Multiplica el esfuerzo por un coste horario cargado y suma las consecuencias directas del peor incidente. El tiempo hasta la detección es la más accionable de las cuatro, porque determina lo caro que sale cada uno de los demás incidentes.

¿Necesito ingenieros para montar la monitorización de calidad de datos?

Para las partes que más importan, no. Las reglas valiosas son reglas de negocio —este campo siempre está relleno, este identificador es único, este estado solo toma estos valores, esta tabla se actualiza a diario— y quien las conoce es el propietario de los datos, no un ingeniero. Catalyst lee automáticamente la estructura de tu tabla y propone un conjunto inicial de comprobaciones, así que el trabajo pasa a ser revisar y ajustar en lugar de escribir código.

¿No hace ya esto nuestro almacén de datos?

Los warehouses imponen estructura, no significado. Te impedirán meter texto en una columna numérica, pero aceptarán encantados un pedido con total negativo, un cliente duplicado cuatro veces o una tabla que no se actualiza desde el jueves. Varios warehouses populares ni siquiera aplican restricciones de unicidad: mira las notas sobre Redshift y BigQuery, donde las claves primarias declaradas no se comprueban nunca. El hueco entre “estructuralmente válido” y “realmente correcto” es donde viven los incidentes de datos.