Calidad de datos y controles verificables para tomar mejores decisiones

Por Oscar Caita · Docente y consultor · oscarcaita.com

Una empresa puede calcular correctamente un indicador y aun así tomar una mala decisión. Basta con que el informe use pedidos duplicados, inventarios desactualizados o registros incompletos. La calidad de datos permite comprobar si la información es adecuada para el uso que se le dará; los controles verificables permiten demostrar qué se revisó, quién actuó y cómo se resolvieron las fallas.

La calidad de datos determina si una empresa puede confiar en la información que utiliza para decidir. Un registro puede estar completo y ser incorrecto, cumplir un formato y llegar demasiado tarde, o coincidir entre sistemas y estar duplicado. Esta guía explica seis atributos de calidad, cómo medir la oportunidad del dato y cómo asignar responsabilidades y diseñar controles verificables, con ejemplos aplicables a estudiantes, profesionales y empresarios.

Este artículo explica cómo reconocer problemas de datos, medirlos y diseñar controles útiles, orientado para estudiantes que quieren comprender los sistemas de información, profesionales que elaboran reportes y empresarios que necesitan decidir con mayor confianza. El caso central es una red de citas ambulatorias ficticia; sus cifras son hipotéticas y no corresponden a una institución real.

La recomendación inicial es elegir una decisión concreta y revisar los datos que la sostienen. Para asignar cupos hoy, interesa conocer la disponibilidad actual. Para analizar un cierre mensual, también importa que el período esté completo y que las reglas de cálculo sean estables.

Qué significa calidad de datos

Un dato es una representación de un hecho o una entidad: la cantidad recibida de un producto, la fecha de una cita o el estado de un pedido. La calidad depende de qué tan bien esa representación sirve a la decisión. El marco de calidad de datos de GOV.UK utiliza este criterio de adecuación al propósito y recoge seis dimensiones que conviene evaluar [1].

Dimensión	Ejemplo de falla en una empresa
Exactitud	El sistema registra 80 unidades, pero el conteo físico confirma 60.
Completitud	El pedido carece de dirección y no puede despacharse.
Consistencia	El mismo pedido figura cancelado en ventas y activo en bodega.
Oportunidad	La cancelación se informa después de preparar el envío.
Validez	Se registra una fecha imposible o un estado fuera del catálogo permitido.
Unicidad	Un reintento del portal crea dos registros del mismo pedido.

Un campo lleno puede contener un valor equivocado. Un correo con formato válido puede pertenecer a otra persona. Dos sistemas pueden coincidir y repetir el mismo error. Por eso, cada dimensión requiere una comprobación diferente y una referencia apropiada.

Diferencias entre atributos en un mismo registro

Comparemos los atributos con un mismo objeto: la cancelación de una cita. El registro esperado contiene ID de cita, paciente, estado, hora del evento, hora de actualización y canal. Las situaciones siguientes son variantes independientes; no se supone que todas ocurran a la vez.

Atributo	Qué se comprueba	Falla ilustrativa
Exactitud	Correspondencia con el hecho.	La persona canceló, pero el registro dice atendida.
Completitud	Presencia del evento y campos necesarios.	La cancelación existe, pero no tiene hora de origen.
Consistencia	Concordancia entre representaciones.	El portal dice cancelada y la agenda dice confirmada.
Oportunidad	Disponibilidad dentro del plazo requerido.	La actualización tarda siete minutos y el plazo es cinco.
Validez	Cumplimiento de formatos y reglas.	El campo contiene un estado fuera del catálogo.
Unicidad	Un solo registro por evento legítimo.	Un reintento crea otra cancelación del mismo evento.

Exactitud y validez

“Confirmada” puede ser un estado permitido y, por tanto, válido. Si la cita fue cancelada, no representa el hecho y carece de exactitud. Validar un catálogo no sustituye contrastar la operación. Para comprobar exactitud se necesita una referencia confiable, como el evento original confirmado.

Completitud y oportunidad

Un registro con todos sus campos puede llegar tarde. Otro puede llegar en segundos, pero sin el ID que permite aplicarlo a la cita correcta. Además, una base con filas completas puede omitir una cancelación entera: conviene revisar presencia de eventos y campos, no solo celdas vacías.

Consistencia y unicidad

Dos agendas pueden coincidir y repetir un estado equivocado. Dos filas iguales pueden ser un duplicado, mientras que dos cancelaciones de citas distintas del mismo paciente son eventos legítimos. Definir qué entidad o evento se representa evita confundir repetición de valores con duplicación indebida.

Trazabilidad seguridad y significado del dato

La trazabilidad permite reconstruir el origen y los cambios de un registro. La seguridad protege su acceso, uso y conservación. En esta guía se presentan como condiciones complementarias de gestión, sin afirmar que la lista de seis dimensiones sea una clasificación universal. ISO/IEC 25012 ofrece un modelo general de calidad de datos estructurados y contempla una clasificación más amplia [2].

Antes de medir hay que acordar qué se está midiendo

Supongamos que dos áreas calculan ventas. Una incluye pedidos confirmados y otra solo facturas emitidas. Sus resultados pueden diferir sin que haya un error de digitación. El problema aparece cuando ambos informes se llaman “ventas del mes” y el lector cree que representan lo mismo.

Un diccionario de datos documenta el significado de cada campo y sus reglas. Para “fecha de entrega”, debe aclarar si corresponde a la promesa al cliente, al despacho o a la recepción efectiva. También debe precisar formato, zona horaria, fuente, responsable y tratamiento de valores ausentes.

Campo	Definición y regla propuesta
ID de cita	Identificador único del evento; no confundir con el documento de la persona.
Estado de cita	Solicitada, confirmada, cancelada o atendida, con transiciones autorizadas.
Hora de cancelación	Momento del evento en el canal de origen, con zona horaria documentada.
Hora de actualización	Momento en que la cancelación queda disponible en la agenda central.

El mismo valor puede tener usos distintos

La demora entre cancelación y actualización permite evaluar oportunidad. La diferencia entre solicitud y confirmación mide tiempo de asignación. Mezclar estas marcas de tiempo produce indicadores ambiguos, aunque la fórmula de promedio esté bien calculada.

Para un pequeño negocio, el diccionario puede empezar en una hoja compartida. Lo esencial es tener una versión controlada, un responsable y reglas aplicadas por todos los canales.

Caso práctico de una red de citas ambulatorias

Una red ficticia recibe solicitudes por portal, teléfono y ventanilla. Su informe semanal muestra un promedio de asignación de ocho minutos. Sin embargo, algunos usuarios reciben confirmaciones repetidas y ciertos cupos cancelados siguen apareciendo ocupados. El promedio informa sobre velocidad, pero no demuestra que la agenda sea confiable.

En el ejercicio se revisan 1.000 registros del período: 20 carecen de algún campo obligatorio; 50 se actualizan después del límite interno propuesto de cinco minutos; 30 son registros excedentes identificados como duplicados indebidos. Una misma fila puede presentar varias fallas. No sería correcto concluir que hay 100 registros distintos afectados.

Qué se sabe y qué debe investigarse

La revisión confirma incumplimientos de reglas en esos registros. Todavía no permite atribuirlos a una persona, a una falla del portal o a la integración entre sistemas. Entre las hipótesis están un reintento que crea otra cita, una sincronización tardía o una regla de identificación incompleta. Para verificarlas se necesitan eventos del sistema, horas de origen y actualización, canal y resultado de cada intento.

Una cita repetida para una misma persona no siempre es un duplicado. Puede corresponder a servicios diferentes o a una reprogramación legítima. La regla debe definir qué combinación de paciente, servicio, horario y estado constituye una duplicación indebida, y qué excepciones están autorizadas.

Cómo distinguir evidencia inferencia y supuesto

La evidencia es información examinable y contrastable que sustenta una afirmación. En el caso incluye el registro del evento, su ID, las marcas de tiempo y la consulta a la agenda central. Su fuerza depende de procedencia, integridad y pertinencia. Una captura sin fecha o un comentario de un usuario puede orientar una revisión, pero no prueba toda la secuencia.

La inferencia es una conclusión razonada a partir de evidencia y premisas. Si el mismo evento aparece a las 08:40 en origen y a las 08:47 en la agenda, inferimos un retraso de siete minutos, siempre que los relojes sean comparables. Atribuirlo a una cola de integración es una hipótesis causal: requiere registros técnicos que la respalden.

El supuesto es una condición aceptada para desarrollar el análisis, aunque no se haya comprobado o se haya elegido para el ejercicio. Aquí adoptamos un plazo interno de cinco minutos. En una empresa debe aprobarlo el dueño según la necesidad operativa. Si asumimos relojes sincronizados, debemos verificarlo antes de presentar el retraso como una medición confiable.

Redacte según el grado de certeza: “el registro muestra” introduce evidencia; “bajo estas condiciones se concluye” expresa inferencia; “para el análisis se adopta” declara un supuesto. La diferencia protege la calidad del argumento: una causa probable no debe presentarse como un hecho confirmado.

Cálculo explicado de la oportunidad del dato

La oportunidad exige que el dato esté disponible a tiempo para su uso. Una cancelación debe hacerse visible en la agenda que consulta quien asigna cupos. Se distingue la hora del evento en origen de la hora en que el cambio puede utilizarse para decidir.

Paso 1 Identificar tiempos comparables

Para C003, el evento ocurre a las 08:40 y queda disponible a las 08:47. Ambas horas corresponden a la misma fecha y zona horaria. Verifique identidad del evento, sincronización de relojes y significado de las marcas. La hora de creación de un reporte no necesariamente es la hora de disponibilidad del dato.

Paso 2 Restar y comparar

Retraso = hora de disponibilidad − hora del evento = 08:47 − 08:40 = 7 minutos. Plazo adoptado = 5 minutos. Exceso = máximo entre 0 y retraso − plazo = 7 − 5 = 2 minutos. C003 incumple porque 7 > 5.

Paso 3 Interpretar el resultado

Durante esos siete minutos la agenda puede seguir mostrando el cupo como ocupado. Los dos minutos de exceso indican cuánto superó el plazo; no demuestran automáticamente una pérdida de cupo o dinero. El estado debe comprobarse antes de reasignar y la causa debe investigarse.

Un retraso de exactamente cinco minutos cumple si la regla es “menor o igual a cinco”. Si un evento ocurre a las 23:58 y queda disponible a las 00:03 del día siguiente, tarda cinco minutos: se restan fecha y hora completas. Un resultado negativo exige revisar reloj o registros, no interpretarlo como mayor rapidez.

Cumplimiento de oportunidad en varios eventos

Esta muestra hipotética de cinco cancelaciones es un ejercicio separado de los 1.000 registros semanales. El corte es a las 09:30 y el plazo de actualización es de cinco minutos para todos los eventos.

Evento	Origen	Disponible	Retraso	Resultado
C001	08:10	08:14	4 min	Cumple
C002	08:25	08:30	5 min	Cumple
C003	08:40	08:47	7 min	Incumple
C004	09:00	09:03	3 min	Cumple
C005	09:20	Pendiente	Al menos 10 min	Incumple al corte

Calcular el porcentaje

Cumplimiento = eventos disponibles dentro del plazo / eventos cuyo plazo ya venció al corte × 100. Los cinco agotaron su plazo antes de las 09:30. Tres cumplen: C001, C002 y C004. Resultado = 3 / 5 × 100 = 60 %. C005 permanece en el denominador: su plazo venció y no se ha actualizado.

Un evento cuyo plazo aún no vence se reporta pendiente de evaluación. Si falta la hora de origen, el retraso no puede calcularse: se informa esa falta de completitud y cuántos eventos son evaluables. No se eliminan silenciosamente los casos que no permiten medir.

Distinguir promedio y cumplimiento

En los cuatro eventos actualizados, retraso promedio = (4 + 5 + 7 + 3) / 4 = 4,75 minutos. Aunque está por debajo de cinco, C003 incumplió y C005 sigue pendiente. El promedio describe solo los cuatro finalizados; debe acompañarse del cumplimiento y del número y antigüedad de casos abiertos.

Comunicar el resultado sin ocultar pendientes

Un reporte claro indica: “tres de cinco eventos cumplieron al corte de las 09:30, equivalente al 60 %; uno llegó tarde y otro seguía sin actualizar”. Identifica resultado, universo y momento. Para automatizar, conserve fechas y horas completas y documente el tratamiento de pendientes.

Cómo transformar una falla en un riesgo concreto

El análisis empieza por un hecho observable. “La base es mala” no orienta una intervención. “La cancelación C042 quedó disponible 42 minutos después de registrarse en el portal” sí permite revisar un evento y valorar su efecto sobre la asignación de cupos.

Elemento	Aplicación al caso ficticio
Evidencia	ID C042 y marcas de tiempo del portal y de la agenda.
Causa probable	Retraso de integración; pendiente de confirmar en registros técnicos.
Evento de riesgo	El sistema trata como ocupado un cupo que ya fue cancelado.
Impacto posible	Se aplaza una asignación o se realiza una revisión manual innecesaria.
Decisión afectada	Ofrecer disponibilidad actual a quien solicita una cita.

Priorizar con criterios explícitos

Una matriz de probabilidad e impacto ayuda a ordenar la revisión cuando el equipo no puede atender todas las fallas a la vez. Propongo una escala sencilla de 1 a 3: probabilidad ocasional, recurrente o frecuente; impacto menor, relevante o crítico. Antes de usarla, el equipo debe traducir cada nivel a criterios observables de su operación.

Por ejemplo, un retraso recurrente con impacto relevante recibe 2 × 2 = 4. El resultado permite comparar prioridades dentro de esa escala; no representa una pérdida monetaria ni una probabilidad estadística. Si no existen registros suficientes, debe declararse que la valoración es preliminar.

Calcular el costo sin contar dos veces

Una estimación operativa puede sumar horas de reproceso por costo de hora, gastos directos de corrección y pérdidas comprobadas. Si 30 duplicados requieren 12 minutos de revisión cada uno, el trabajo suma 360 minutos, equivalentes a seis horas. Con un costo hipotético de $25.000 COP por hora, el reproceso sería de $150.000 COP. No es una tarifa de mercado ni una pérdida total demostrada.

El análisis debe indicar el período, el alcance y las partidas incluidas. Las ventas potenciales y los efectos sobre confianza requieren evidencia adicional antes de presentarse como dinero perdido.

Cómo diseñar controles verificables

Un control verificable precisa una acción, una persona o rol responsable, un momento de ejecución, la evidencia que conserva y el indicador que permite evaluarlo. Una instrucción como “revisar la información” deja sin resolver esos elementos.

Un control preventivo debe permitir las operaciones legítimas

Antes de confirmar una cita, el sistema debe comprobar disponibilidad y aplicar la regla de duplicación acordada. Si llegan dos solicitudes simultáneas, una validación en pantalla puede ser insuficiente: la confirmación central debe impedir que ambas ocupen el mismo cupo. Los reintentos deben reconocer la solicitud original para evitar crear nuevos eventos por la misma operación.

Una alerta necesita una ruta de atención

El control detectivo puede comparar, cada minuto en el piloto, las agendas de los tres canales e identificar estados contradictorios. Debe crear una excepción con ID, regla incumplida y responsable. Enviar un correo sin seguimiento deja abierta la duda de si alguien atendió la falla.

Corregir exige conservar la historia

El control correctivo resuelve el duplicado confirmado o la cancelación pendiente y verifica la actualización en todos los canales. La evidencia registra el motivo, el valor anterior, el valor nuevo y la aprobación requerida. La autorización depende del impacto del cambio; no toda corrección necesita el mismo nivel de aprobación.

Ficha completa del control preventivo

El preventivo actúa antes de confirmar. Aquí impide que un reintento cree otra cita del mismo evento o que solicitudes simultáneas ocupen el mismo cupo. La regla debe reconocer eventos y excepciones legítimas.

Elemento	Diseño propuesto
Riesgo	Confirmación duplicada o reserva de un cupo ocupado.
Acción	Reconocer ID original y comprobar y reservar disponibilidad como una operación indivisible.
Responsable	Dueño aprueba regla; sistemas configura; coordinación revisa rechazos.
Momento	Cada confirmación, en todos los canales.
Evidencia	ID original, intento, versión de regla, hora, resultado y vínculo a la cita existente.
Indicador	Reintentos que devuelven la cita original / reintentos válidos de prueba × 100.
Excepción	Solicitudes distintas y reprogramaciones autorizadas se revisan sin asumir duplicación por paciente.

Prueba y cálculo

Se reenvían 20 solicitudes ya confirmadas en un entorno de prueba. Diecinueve devuelven la cita original y una crea otra. Resultado = 19 / 20 × 100 = 95 %. El control falla en un escenario conocido y debe ajustarse. El porcentaje describe esa prueba, no todos los eventos reales.

Reservar de forma indivisible significa comprobar y ocupar el cupo mediante una operación central que no permita dos confirmaciones simultáneas. Reconocer el ID original evita volver a crear una operación en un reintento. La regla debe actuar donde se confirma definitivamente, aunque la pantalla también avise.

Comprobar operaciones legítimas

Pruebe solicitudes de distintos servicios y reprogramaciones permitidas. Mida rechazos indebidos y su carga de revisión. Contar bloqueos no basta: algunos pueden ser falsos positivos. Conserve resultados y versión de regla para reconstruir por qué un intento fue aceptado o rechazado.

Ficha completa del control detectivo

El detectivo identifica una discrepancia en curso. Para observar incumplimientos cercanos al plazo de cinco minutos, se propone comparar cada minuto en el piloto. La frecuencia debe validarse con el riesgo y la capacidad técnica.

Elemento	Diseño propuesto
Riesgo	Cancelación no visible dentro del plazo acordado.
Acción	Comparar origen y agenda; abrir excepción cuando vence el plazo.
Responsable	Sistemas ejecuta comparación; coordinación valida y atiende alertas.
Momento	Cada minuto en el piloto; revisión de alertas vencidas.
Evidencia	ID, horas, regla, hora de alerta, responsable asignado y estado del caso.
Indicador	Fallas conocidas alertadas dentro de un minuto del vencimiento / fallas conocidas probadas × 100.
Excepción	Fuentes caídas o relojes no comparables generan aviso de medición no confiable.

Prueba y cálculo

Se introducen 10 eventos que superan cinco minutos sin actualizarse. Nueve generan alerta dentro del minuto siguiente al vencimiento; uno no. Resultado = 9 / 10 × 100 = 90 %. Ese caso exige revisar cobertura, ejecución o lógica de comparación. Se utilizan fallas conocidas porque “cero alertas” no demuestra ausencia de errores.

La alerta abre una investigación

El validador contrasta identidad y estado con la fuente y deriva la falla confirmada al correctivo. La alerta no cambia por sí sola una cita. El registro distingue detectada, en revisión, confirmada y cerrada, para evitar que “atendida” se interprete como “resuelta”.

En operación, observe alertas confirmadas y casos abiertos vencidos. Una detección puede ser correcta y tardía: compruebe cobertura y momento. Mantenga separados resultados de prueba y resultados del período real. En cada turno debe quedar definido quién recibe el caso y a quién escala si no puede resolverlo.

Ficha completa del control correctivo

El correctivo repara una falla confirmada y comprueba el resultado. Actualiza una cancelación pendiente o resuelve un duplicado con la autorización correspondiente, sin borrar operaciones legítimas ni perder el historial.

Elemento	Diseño propuesto
Riesgo	Persistencia del estado errado o corrección que ocasiona otra asignación indebida.
Acción	Contrastar, autorizar cuando corresponda, corregir y verificar todos los canales.
Responsable	Coordinación valida; responsable autorizado aprueba cambios sensibles; sistemas interviene si hace falta.
Momento	Tras confirmar la falla; plazo de cierre propuesto de 15 min desde la validación.
Evidencia	Caso, valores anterior y nuevo, motivo, ejecutor, aprobación, horas y prueba de sincronización.
Indicador	Casos corregidos y verificados dentro de 15 min / casos confirmados cuyo plazo venció × 100.
Excepción	Si el cupo ya fue reasignado, escalar antes de cambiar y documentar contención.

Prueba y cálculo

En un piloto, ocho casos confirmados agotaron su plazo al corte. Seis se corrigieron y verificaron dentro de quince minutos, uno cerró después y otro sigue abierto. Resultado = 6 / 8 × 100 = 75 %. El abierto permanece en el denominador; no se excluye para mejorar el resultado.

Quince minutos es un supuesto didáctico distinto del plazo original de cinco para actualizar el dato. Corregir a tiempo el incidente no vuelve oportuno, retroactivamente, un dato tardío. Cada indicador tiene su propio inicio, final y universo.

Cierre y prevención de recurrencia

El cierre exige prueba del estado resultante, no solo una tarea marcada como terminada. Después se investiga la causa y se ajusta el preventivo o la integración cuando la evidencia lo justifique. Corregir C003 resuelve ese evento; reparar la causa requiere otra intervención y pruebas de que el problema no se repite.

Ficha de control y responsabilidades

Componente	Control propuesto para cancelaciones
Riesgo	Ofrecer una agenda con cupos ocupados que ya fueron cancelados.
Acción	Comparar la cancelación de origen con el estado en la agenda central.
Responsable	Coordinación de agenda atiende; tecnología investiga fallas de integración.
Momento	Comparación cada minuto; actualización esperada dentro de cinco minutos en este ejemplo.
Evidencia	ID, tiempos, canal, discrepancia, responsable, corrección y comprobación final.
Excepción	Si se supera el plazo, abrir caso y verificar disponibilidad antes de reasignar.
Indicador	Porcentaje de cancelaciones disponibles dentro del plazo y casos aún abiertos.

Cinco minutos para actualizar y una comparación cada minuto son parámetros didácticos, no estándares universales. Una revisión horaria puede detectar tarde fallas que afectan decisiones en minutos. El dueño aprueba el plazo y el equipo comprueba que puede medirlo y atender sus excepciones.

Quién decide quién ejecuta y quién comprueba

El dueño del dato, desde el negocio, aprueba el significado, la regla y el umbral. El productor registra la operación. El custodio tecnológico mantiene la plataforma y sus mecanismos de acceso y respaldo. El validador revisa excepciones y documenta la resolución. El usuario del informe comunica inconsistencias y considera sus límites al decidir.

En una empresa pequeña una persona puede cumplir varios roles. Conviene distinguirlos por escrito y establecer una segunda revisión para cambios con consecuencias importantes. La responsabilidad compartida necesita tareas asignadas; de otro modo, cada área puede asumir que la otra ya verificó.

Diseño ejecución y resultado se comprueban por separado

Para evaluar el diseño, se prueba si el control reconoce una falla conocida. Para comprobar la ejecución, se revisa que operó en el período previsto. Para evaluar el resultado, se verifica que la excepción se resolvió y que la decisión usa el dato actualizado. Un registro de ejecución no demuestra, por sí solo, eficacia.

Roles del gobierno del dato aplicados al caso

Gobernar el dato implica asignar autoridad para definirlo, responsabilidades para gestionarlo y criterios para resolver desacuerdos. Los cargos pueden variar; estas funciones deben estar cubiertas. La distribución siguiente es una propuesta para la red ficticia.

Rol	Quién lo ejerce	Responsabilidad en el caso
Dueño	Dirección de operaciones	Aprueba significado de disponibilidad, plazo y excepciones.
Productor	Agente de atención o portal	Registra solicitud o cancelación y conserva evento de origen.
Custodio	Equipo de sistemas	Mantiene integración, accesos, relojes y registro técnico.
Validador o gestor	Coordinación de agenda	Contrasta alertas, coordina resolución y verifica cierre.
Usuario	Equipo que asigna cupos	Consulta estado vigente y comunica contradicciones.

Quién cambia una regla

Si atención propone reducir el plazo a dos minutos, el dueño evalúa el riesgo y aprueba el criterio. El custodio analiza viabilidad técnica. El validador ajusta la revisión y el usuario comprueba si la actualización satisface la necesidad. Cambiar una regla técnica sin acordar su significado puede producir reportes incomparables.

Quién autoriza y quién ejecuta una corrección

El validador investiga y propone corregir C003. Puede ejecutar una corrección rutinaria dentro de una autorización previamente aprobada. Si implica modificar una cita ya asignada a otra persona, escala al responsable autorizado antes de actuar. El custodio facilita el cambio técnico, pero no decide por sí solo qué asignación de negocio es legítima.

Quién comprueba el resultado

El validador confirma sincronización; el usuario comprueba que la disponibilidad se refleja al consultar. El caso conserva ejecutor, aprobación cuando corresponde y verificador. En un negocio pequeño los roles pueden recaer en un mismo cargo; para cambios importantes conviene una revisión adicional. Compartir contraseñas dificulta atribuir acciones.

Indicadores y evidencia para comprobar resultados

Indicador	Cálculo en el ejemplo de 1.000 registros
Completitud por registro	980 registros con todos los campos obligatorios / 1.000 × 100 = 98 %.
Oportunidad	950 actualizados dentro de cinco minutos / 1.000 × 100 = 95 %.
Unicidad operacional	(1.000 − 30 registros duplicados excedentes) / 1.000 × 100 = 97 %.
Validez	Registros que pasan todas las reglas definidas / registros evaluados × 100.
Exactitud verificada	Valores que coinciden con una referencia comprobada / valores contrastados × 100.

Estas son definiciones operativas propuestas. Para unicidad se cuentan registros excedentes, no grupos duplicados ni todos los integrantes de esos grupos. Para exactitud, el resultado solo describe los valores contrastados; si provienen de una muestra, deben informarse su selección, tamaño y limitaciones.

Cada indicador necesita período, fuente, unidad de análisis, numerador, denominador y exclusiones. Si se cambia la regla o el universo, la comparación con períodos anteriores debe explicarlo. Cuando no existen registros aplicables, el resultado se reporta como “no aplica”, en lugar de dividir entre cero.

La evidencia debe conservarse con acceso limitado y durante el plazo definido por la organización. En reportes de aprendizaje o difusión se usan identificadores ficticios o información anonimizada. Un respaldo ayuda a recuperar datos, pero no confirma que fueran correctos antes de guardarlos.

Cómo empezar en una empresa o en el aula

Una ruta inicial de cuatro semanas

• Semana 1. Elegir una decisión recurrente, identificar sus campos críticos y acordar el significado de cada uno. Entregable: diccionario y mapa de fuentes.
• Semana 2. Revisar un período representativo y registrar fallas por regla, canal y momento. Entregable: línea base con evidencia y límites de la revisión.
• Semana 3. Probar un control prioritario con casos válidos, fallas conocidas, reintentos y excepciones legítimas. Entregable: ficha de control y resultados de prueba.
• Semana 4. Comparar con la línea base y revisar tiempos de atención, recurrencia y carga de trabajo. Entregable: decisión documentada de ajustar, ampliar o reemplazar el control.

En inventarios, se puede iniciar por la disponibilidad de los productos más vendidos. En ventas, por la identificación de clientes y pedidos. En producción, por unidades de medida, cantidades y estados de las órdenes. El alcance debe ser pequeño para que la revisión produzca cambios comprobables.

Ejercicio para estudiantes y equipos de trabajo

Seleccione un reporte y pregunte: ¿qué decisión permite tomar?, ¿qué campo podría cambiar esa decisión si estuviera equivocado?, ¿qué evidencia sirve para contrastarlo?, ¿en qué momento debe revisarse? Luego redacte un control con acción, responsable, momento, evidencia e indicador. Presente un caso en el que opere bien y otro en el que deba manejar una excepción.

Errores que conviene evitar

Eliminar duplicados sin investigar puede borrar operaciones válidas. Completar campos con “N/A” solo para mejorar un porcentaje puede ocultar ausencia de información. Una tasa alta de calidad puede esconder una falla crítica si se promedian dimensiones sin considerar su impacto. Automatizar reglas ambiguas reproduce el problema con mayor velocidad.

Los falsos positivos también tienen costo: una alerta que marca como duplicados muchos eventos legítimos consume tiempo y reduce confianza en el control. Conviene medir alertas confirmadas, casos vencidos y reincidencias, además del número de revisiones ejecutadas.

Preguntas frecuentes sobre calidad de datos

Cuál es la diferencia entre calidad y limpieza de datos

La limpieza corrige errores detectados, como espacios o formatos. La gestión de calidad también define reglas, identifica causas y comprueba si los datos sirven para decidir. Una base limpia hoy puede volver a deteriorarse mañana si el origen sigue produciendo la falla.

Excel es suficiente para comenzar

Puede servir para documentar campos, registrar excepciones y calcular una línea base cuando el volumen y el trabajo simultáneo son manejables. Si varias personas cambian versiones sin control o los datos deben sincronizarse rápidamente, se necesitan mecanismos adicionales de integración y seguimiento.

Cuál dimensión debe atenderse primero

La que más afecta la decisión prioritaria. Para ofrecer un cupo disponible, la oportunidad puede ser decisiva. Para realizar un pago, importan la identificación y el valor correcto. La prioridad debe justificarse por el efecto de la falla.

Una herramienta de inteligencia artificial resuelve el problema

Puede apoyar la identificación de patrones o la clasificación de excepciones, pero sus resultados requieren validación. Hay que definir la regla, comprobar errores y proteger la información utilizada. Un texto convincente o una predicción coherente no sustituyen la evidencia de la operación.

Cómo saber si un control funciona

Compruebe que detecta o evita la falla prevista, que se ejecuta cuando corresponde y que deja evidencia del resultado. Después observe si el problema vuelve a ocurrir y si el control bloquea operaciones válidas o genera una carga excesiva.

La próxima decisión puede ser el punto de partida

Antes de aprobar el próximo informe, elija un dato crítico y pida su definición, origen y comprobación. Esa revisión permite pasar de una cifra aparentemente correcta a una decisión con fundamento. Si su organización necesita estructurar esta revisión, puede consultar con Oscar Caita el alcance de un diagnóstico de datos y controles para sus procesos.

Fuentes y criterios de elaboración

Las definiciones generales se apoyan en fuentes públicas. Las cifras, fichas, escenarios y ruta de implementación son propuestas didácticas de Oscar Caita. El caso ambulatorio se utiliza para explicar gestión de información y no constituye una recomendación clínica.

[1] Government Data Quality Hub. (2020). The Government Data Quality Framework. GOV.UK. https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework

[2] ISO/IEC. (2008). ISO/IEC 25012:2008. Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model. Ficha pública del estándar. https://www.iso.org/standard/35736.html

La referencia a ISO se limita al alcance y propósito publicados en su ficha pública. Este artículo no reproduce la norma ni acredita cumplimiento o certificación. El marco de GOV.UK recoge las seis dimensiones de DAMA UK; esta guía las utiliza como una base práctica y no como una lista exhaustiva.

Lecturas complementarias del documento original

DAMA International. (2017). DAMA DMBOK Data Management Body of Knowledge (2.ª ed.). Technics Publications.

Laudon, K. C., y Laudon, J. P. (2022). Management Information Systems (17.ª ed.). Pearson.

Estas dos obras se conservan como lecturas complementarias del original. No se les atribuyen citas textuales ni páginas que no se hayan consultado.

Fuentes para configurar la publicación

Google Search Central. Documentación de Article y Search Essentials. https://developers.google.com/search/docs/appearance/structured-data/article y https://developers.google.com/search/docs/essentials

Consulta de fuentes públicas: 1 de octubre de 2026. Autoría del artículo y de sus piezas gráficas: Oscar Caita.Oscar Caita · oscarcaita.com