Mejorar la calidad de los datos: comprobaciones prácticas que en 30 días proporcionan informes mediblemente mejores

Muchas empresas intentan obtener mejores informes mediante nuevos dashboards, KPIs adicionales o una herramienta BI distinta. En la práctica, el problema suele estar antes: quien quiere mejorar la calidad de los datos debe estabilizar los datos en los puntos en que se generan, se transfieren, se agregan y se interpretan. La mala calidad de los datos no solo se manifiesta en «números incorrectos», sino en el día a día: las áreas de negocio discuten sobre la fuente en lugar de sobre la decisión, TI recibe tickets de «el informe no coincide», y cada análisis requiere correcciones manuales en Excel.

Lo bueno: para mejoras perceptibles no hace falta un programa de gran envergadura. Con un enfoque claro de 30 días —centrado en pocas pero efectivas comprobaciones— se pueden estabilizar los informes de forma medible. Es crucial que las comprobaciones no se entiendan como una limpieza puntual, sino como un sistema de control operativo: con límites, responsables, documentación y vías de escalado.

Esta entrada describe comprobaciones de calidad de datos prácticas que puede implantar en cuatro semanas, sin «reinventar» el paisaje de sistemas. El foco está en las repercusiones para la operación, la administración, las interfaces, los flujos de datos y la colaboración entre TI y el área de negocio.

Por qué fallan los informes pese a herramientas modernas: causas típicas en entornos empresariales

En entornos evolucionados los datos se generan a través de muchas estaciones: ERP, CRM, almacén, portales, software empresarial a medida, procesos de importación/exportación, interfaces con proveedores de servicios. Cada estación puede cambiar el significado de un campo. Un ejemplo clásico es «cliente»: en el sistema A es el receptor de la factura, en el sistema B la dirección de entrega, en el sistema C la ubicación. En cuanto estos términos se consolidan en un análisis, surgen aparentemente indicadores «incorrectos», aunque técnicamente todo se haya cargado correctamente.

Causas típicas que hacen que los informes sean poco fiables:

• Semántica poco clara: los campos se llaman igual, pero significan algo distinto en cada sistema. Aquí semántica se refiere al significado funcional, no al formato de datos.
• Fallos silenciosos en las interfaces: un campo se modifica en una fuente (p. ej. nuevos valores de estado), la trayectoria destino lo incorpora «como siempre» hasta que los análisis se desequilibran.
• Datos maestros débiles: duplicados, direcciones obsoletas, catálogos de productos inconsistentes —y las asignaciones erróneas que de ello derivan.
• ETL/ELT sin puertas de calidad: ETL (Extract, Transform, Load) se refiere a las rutas de carga y transformación hacia un DWH. Sin comprobaciones, lo defectuoso se carga tal cual.
• Correcciones manuales: las soluciones en Excel generan lógica en la sombra. El informe parece «correcto», pero no es reproducible.

La consecuencia es siempre similar: falta un mecanismo fiable que detecte las desviaciones de forma temprana y las haga trazables antes de que lleguen a los informes de gestión.

Medible en 30 días: qué significa concretamente «mejor calidad de datos»

«Mejor» debe ser medible, de lo contrario queda en una sensación. Para un plan de 30 días es útil acordar pocos indicadores que tanto TI como el área de negocio acepten. Han demostrado ser útiles tres niveles:

• Calidad de entrada: proporción de registros válidos en la fuente (p. ej. pedidos con dirección de entrega completa).
• Calidad de la canalización: proporción de jobs de carga verificados con éxito sin violaciones de calidad (p. ej. sin valores atípicos, sin valores nulos inesperados).
• Calidad del informe: número de reclamaciones sobre informes, tiempo hasta su resolución, número de correcciones manuales.

Apunte a un alcance inicial pequeño: dos o tres informes críticos que se utilicen con regularidad (p. ej. Umsatz/Deckungsbeitrag, Liefertermintreue, Bestandskennzahlen). Para estos informes defina “campos críticos” y construya comprobaciones precisamente allí. Esto evita que la calidad de los datos se convierta en una obra interminable.

Mejorar la calidad de los datos con 5 categorías de comprobación que funcionan en cualquier entorno

Las siguientes categorías de comprobación están seleccionadas para funcionar independientemente de la herramienta BI utilizada. Pueden implementarse en la base de datos, en la canalización ETL o como trabajos de control independientes. Lo importante no es la herramienta, sino la aplicación consistente.

1) Comprobaciones de completitud: los campos obligatorios están realmente rellenados

La completitud es la palanca más rápida porque suele poder comprobarse sin lógica compleja. Ejemplos típicos: ID de cliente, número de artículo, fecha de contabilización, centro de costes, estado, moneda. La trampa habitual en la práctica: que un campo no sea „NULL“ no es suficiente. Un campo puede estar técnicamente relleno pero estar vacío desde el punto de vista funcional (p. ej. „0“, „–“, „desconocido“).

Reglas prácticas:

• Defina por informe 10–20 campos obligatorios que realmente sean relevantes para los indicadores.
• Diferencie entre duro (el informe no debe actualizarse) y blando (el informe se actualiza, pero con advertencia y ticket).
• Haga seguimiento de la tasa: „X% de los registros cumplen todos los campos obligatorios“ – eso es medible en 30 días.

2) Comprobaciones de validez: rango de valores, formato y convenciones funcionales

Validez significa que un valor no solo está presente, sino que es plausible dentro del ámbito permitido. Puede ser técnico (fecha en formato ISO) o funcional (el estado es uno de los valores permitidos). Especialmente en interfaces suele aparecer nuevos valores “inesperados”. Una comprobación de validez actúa como un sistema de aviso temprano para esos cambios.

Ejemplos de comprobaciones de validez robustas:

• Enumeraciones (listas de valores): valores de estado, tipos de documento, tipos de asiento.
• Rangos de valores: cantidades >= 0, descuentos entre 0 y 100, fecha de contabilización no en el futuro (con excepción definida).
• Reglas de formato: longitud del código postal según el país, formato IBAN, reglas de correo electrónico (con tolerancia para no bloquear casos excepcionales legítimos).

Es importante gestionar las excepciones de forma deliberada: una comprobación demasiado estricta conduce a procesos de evasión („entonces pondremos 999“). Defina por tanto una clase de excepción con motivo documentado y fecha de caducidad.

3) Comprobaciones de consistencia: la misma entidad debe ser igual en todas las tablas

La consistencia es la razón más frecuente de informes contradictorios. Casos típicos: un pedido está „finalizado“, pero aún existen partidas abiertas. Un cliente está „inactivo“, pero tiene nuevas contabilizaciones. Un artículo está „bloqueado“, pero se está gestionando su aprovisionamiento. Las comprobaciones de consistencia verifican las relaciones entre campos y tablas.

Comprobaciones prácticas de consistencia que muestran efecto rápidamente:

• Lógica de estado: un estado final requiere fecha de finalización; una anulación requiere motivo de anulación.
• Integridad referencial: cada asiento tiene un centro de costes válido; cada posición tiene un maestro de artículos válido. (Aunque la base de datos no imponga claves externas, la comprobación puede monitorizarlo.)
• Conciliación de totales: suma de posiciones = importe del documento (con tolerancia por redondeo).

Estas comprobaciones son especialmente valiosas porque hacen visibles rupturas semánticas que de otro modo solo aparecerían en reuniones. Para las operaciones de IT y la dirección de proyecto, las comprobaciones de consistencia son un buen indicador de si los cambios en el sistema origen se reflejan.

4) Comprobaciones de duplicados e identidad: „Un cliente“ es realmente un cliente

Los duplicados casi siempre surgen por límites de procesos y sistemas: nuevos canales de venta, portales, creación manual, migraciones. El área de negocio lo detecta como ventas duplicadas, segmentación errónea o responsabilidades poco claras. IT suele ver solo claves diferentes.

Enfoque pragmático sin un gran proyecto de gestión de datos maestros:

• Defina una o dos reglas de emparejamiento para los dominios maestros más importantes (p. ej. Cliente: Nombre+código postal (PLZ)+Calle; Proveedor: USt-ID o IBAN).
• Implante un informe de „sospecha de duplicado“: no como eliminación automática, sino como lista de trabajo con propietario.
• Establezca un conjunto de reglas de adopción: ¿qué fuente de datos es la principal (System of Record) para la dirección, las condiciones de pago y la clasificación?

El efecto medible tras 30 días no es „no más duplicados“, sino: los duplicados se encuentran más rápido, los responsables los resuelven y los informes clave se distorsionan menos por conteos dobles.

5) Comprobaciones de valores atípicos y de deriva: cuando los números „se comportan de forma extraña“ antes de que escale

Muchos errores de datos no son „NULL“, sino progresivos: una interfaz entrega de repente un 20% menos de registros, un estado se usa de forma distinta, una ubicación contabiliza en moneda incorrecta. Las comprobaciones de deriva analizan tendencias y distribuciones. Son especialmente útiles para métricas operativas que se ejecutan diariamente o semanalmente.

Mecanismos de fácil implementación:

• Comprobación de volumen: número de registros por día/semana dentro de un corredor (p. ej. mínimo/máximo, media móvil).
• Comprobación de distribución: la proporción de ciertos valores de estado o categorías se mantiene dentro del rango esperado (p. ej. „anulado“ no se multiplica por 10 de pronto).
• Comprobación de latencia: tiempo entre el evento en el sistema origen y la disponibilidad en el DWH/Informe (importante para la gestión diaria).

Para que las comprobaciones de deriva sean aceptadas necesitan reglas claras de alarma. Si no, aparece la „fatiga por alertas“: muchas advertencias, poca acción. Defina por tanto qué desviación se limita a registrarse y cuál genera un ticket.

El plan de 30 días: así implementan IT y el área de negocio comprobaciones sin un proyecto colosal

Las siguientes cuatro semanas constituyen un ritmo práctico. Es adecuado tanto para configuraciones clásicas de DWH/ETL como para plataformas de datos modernas. El objetivo no es la perfección, sino un ciclo de calidad que funcione.

Semana 1: Establecer el foco – Alcance, fuentes de datos, responsabilidades

Comience con una reunión conjunta de TI y el área de negocio (60–90 minutos). El resultado no es un pliego de requisitos, sino una orden de trabajo con límites claros.

• Elija 2–3 informes que sean críticos para el negocio y se utilicen con regularidad.
• Defina las fuentes de datos y el recorrido hasta el informe: sistema origen → interfaz → Staging/ODS → DWH → BI. (ODS significa Operational Data Store, es decir, un área intermedia para datos operativos.)
• Designe responsables: por informe, un responsable funcional (significado/reglas) y un responsable técnico (pipeline/operación).
• Medir líneas base: tasas de error actuales, número de reclamaciones, causas típicas.

Ya aquí merece la pena una pequeña „lista de términos de datos“: ¿qué significa cada métrica y qué campos la componen? Eso reduce debates posteriores.

Semana 2: Construir comprobaciones – primero integridad y validez

En la semana 2 se crean las primeras pruebas automatizadas. El objetivo es obtener señales rápidamente, sin bloquear la operación diaria.

• Implemente comprobaciones de integridad para los campos obligatorios de los informes seleccionados.
• Añada comprobaciones de validez para valores de estado, rangos de fechas, formatos básicos.
• Defina los resultados de las comprobaciones como eventos: «OK», «Advertencia», «Error». Esta clasificación es operativamente más importante que el texto técnico detallado.

Importante: guarde los resultados de las comprobaciones de forma histórica. De lo contrario, tras dos semanas no podrá decir si ha mejorado. Un simple registro de auditoría por comprobación (momento, fuente afectada, número de incumplimientos) basta para empezar.

Semana 3: Consistencia y Drift – estabilizar los flujos de datos en lugar de solo depurarlos

Ahora se atacan las causas que hacen que los informes sean «inestables». Las comprobaciones de consistencia detectan rupturas entre tablas/sistemas; las comprobaciones de deriva detectan cambios paulatinos.

• Implante 3–5 comprobaciones de consistencia que actúen directamente sobre las métricas del informe (p. ej., conciliación de sumas, lógica de estados).
• Configure 1–2 comprobaciones de deriva por fuente de datos (volumen y latencia suelen ser el mejor punto de partida).
• Establezca una breve revisión semanal (30 minutos): ¿Qué incumplimientos se repiten? ¿Cuáles son errores «reales» y cuáles ajustes de reglas?

Este es el punto en el que la colaboración resulta rentable: muchos «problemas de datos» son problemas de proceso (p. ej., mantenimiento de estados, campos obligatorios en ventas). Cuando el área de negocio es la responsable, surgen medidas concretas en lugar de tickets sin efecto.

Semana 4: Hacer operativo – Eskalation, Tickets, Freigaben, Reporting-Hygiene

Sin anclaje operativo, las comprobaciones se diluyen tras el piloto. La semana 4 aporta rutina y vías claras.

• Reglas de alarma y tickets: ¿Qué clase de comprobación genera automáticamente un ticket? ¿Quién es el destinatario? ¿Qué tiempo de respuesta es realista?
• Protección de releases: ante cambios en interfaces o modelos de datos se comprueba un conjunto mínimo de comprobaciones antes del despliegue a producción (puerta de calidad).
• Listas de trabajo de los responsables de datos: sospecha de duplicados, clasificaciones faltantes, excepciones con fecha de caducidad.

Al final de los 30 días debería tener una hoja de resultados breve: línea base vs. estado actual (tasas de error, reclamaciones, tiempo hasta la resolución). Eso genera confianza – y hace que la siguiente ampliación sea planificable.

¿Dónde es técnicamente más apropiado ubicar las comprobaciones: sistema fuente, interfaz, DWH o BI?

Una pregunta frecuente en los proyectos es: «¿Dónde incorporamos las comprobaciones?» La respuesta depende del impacto y del modo de operación. Regla práctica: compruebe lo antes posible, pero tan cerca del informe como sea necesario.

• En el sistema fuente: Ideal para campos obligatorios y reglas de proceso (p. ej., lógica de estado). Ventaja: los errores ni siquiera se generan. Desventaja: los cambios requieren aprobación del área funcional y pueden afectar procesos.
• En la interfaz: Adecuado para comprobaciones de formato y mapeo. Ventaja: protege los sistemas posteriores. Desventaja: con rechazos severos pueden producirse atascos de datos.
• En el DWH/staging: Adecuado para comprobaciones de consistencia, conciliaciones de totales, controles de volumen y de deriva. Ventaja: centralizado, fácilmente monitorizable. Desventaja: los errores ya se han «ingresado» y deben tratarse de forma retroactiva.
• En el BI: Más como última capa de protección (p. ej., avisos). Ventaja: visible rápidamente para los usuarios. Desventaja: demasiado tarde para corregir las causas de forma adecuada.

Para un arranque de 30 días, el DWH/staging suele ser el lugar pragmático, porque IT tiene allí el control sin intervenir en procesos operativos. A medio-largo plazo conviene desplazar comprobaciones seleccionadas hacia el sistema fuente.

Data Governance ligera: Roles que sostienen realmente la calidad de datos en el día a día

«Data Governance» suena a comités y directrices. Para mejoras rápidas basta un modelo ágil que aclare responsabilidades. En proyectos se han demostrado útiles tres roles:

• Data Owner (área funcional): Responsable del significado, las reglas y las excepciones. Decide si un valor es aceptable desde el punto de vista funcional.
• Data Steward (operativo): Gestiona listas de trabajo (p. ej., duplicados, clasificaciones faltantes) y garantiza el mantenimiento continuo.
• Technical Owner (IT): Opera comprobaciones, monitorización, interfaces y escalados; garantiza trazabilidad (logs, historial, reproducibilidad).

Es importante que las escalaciones no terminen en el vacío: si una comprobación se viola repetidamente, se necesita bien un cambio de proceso, una adaptación de la UI en el software de negocio o una modificación deliberada de la regla. «Ignorar» no es una opción, de lo contrario el sistema de control pierde credibilidad.

Escollos típicos – y cómo evitarlos

Demasiadas comprobaciones a la vez

Si los equipos definen 100 reglas, pero no aplican ninguna de forma sistemática, no se gana nada. Empiece con pocas comprobaciones que actúen directamente sobre los informes seleccionados. Amplíe solo cuando la operación sea estable.

Comprobaciones sin ruta de acción

Una comprobación que solo muestra “rojo” genera frustración. Cada regla necesita un responsable, una forma de gestión (ticket, lista de tareas, proceso) y una decisión sobre si el informe se bloquea o solo se alerta.

“Limpiamos una vez” en lugar de corregir las causas

Una limpieza puntual puede ayudar a mejorar las líneas base. Será sostenible solo si se aborda la causa: campos obligatorios, formularios de entrada, contratos de interfaz, lógica de estado, migraciones. De lo contrario el problema volverá.

Falta de trazabilidad del origen de los datos

Para aclaraciones recurrentes merece la pena una vista simple de Data Lineage: ¿de dónde viene un campo, qué transformaciones se aplican, quién fue el último que lo modificó? Data Lineage es precisamente esa cadena de procedencia. No tiene que venir como una gran herramienta: a menudo basta con una vista mantenida por informe.

Cómo una mejor calidad de datos mejora las decisiones — más allá de “paneles más atractivos”

El beneficio no aparece solo en menos errores, sino en decisiones más rápidas y confiables:

• Menor esfuerzo de coordinación: las reuniones vuelven a centrarse en las acciones en lugar de en las fuentes de datos.
• Análisis de causa más rápido: los historiales de comprobaciones muestran cuándo empezó un error (p. ej., tras un despliegue o un cambio de interfaz).
• Planificación más estable: los pronósticos y las decisiones de inventario se ven menos distorsionados por artefactos en los datos.
• Menos TI en la sombra: si los informes oficiales son fiables, disminuye la presión por crear almacenes propios en Excel.

Para la dirección de TI y los responsables de proyecto es especialmente crucial: la calidad de los datos es un tema a nivel operativo. Conecta arquitectura (flujos de datos), operación (monitorización, tickets), procesos (responsabilidades de mantenimiento) y modernización (interfaces, modelos de datos).

Conclusión: en 30 días, de la disputa por los números a un proceso de calidad controlable

Mejorar la calidad de los datos es menos una cuestión de herramienta que de disciplina: términos claros, pocas comprobaciones eficaces, métricas historizadas y una ruta de acción que funcione en el día a día. Si empieza con 2–3 informes críticos, automatiza rápidamente completitud y validez y luego añade consistencia y deriva, obtendrá en un mes una estabilidad mensurable en los informes —y una base para hacer crecer la gobernanza de datos sin sobrecarga.

Si desea comprobar qué comprobaciones en su entorno de sistemas producen el efecto más rápido y cómo integrarlas operativamente de forma sólida, puede discutirlo en el siguiente paso de manera estructurada:

Para este tema también son importantes Mejorar el reporting y la calidad de los datos maestros. El artículo sitúa estos aspectos de forma comprensible y muestra qué importa en el día a día.

Hablar sobre un proyecto o iniciativa de modernización con Net-Base.