Cómo construir indicadores útiles a partir de datos existentes

Introducción

Una empresa puede conservar miles de pedidos, incidencias, visitas, presupuestos o registros de actividad y, sin embargo, no disponer de una medida fiable para saber si está mejorando. La diferencia no está en acumular información, sino en transformar cada registro en una observación que responda a una decisión concreta. Para conseguirlo hay que precisar cinco elementos desde el principio: pregunta, población, evento, tiempo y validación.

Construir indicadores útiles a partir de datos existentes es un problema práctico de Ciencia de Datos. Implica reconocer cómo se generaron los registros, preparar una tabla de análisis, calcular medidas reproducibles y comprobar que su interpretación sigue siendo correcta cuando cambian el volumen, la composición o la calidad de los datos. Un porcentaje matemáticamente impecable puede ser inútil si mide una población equivocada o mezcla operaciones que no son comparables.

Este artículo desarrolla un método para convertir datos operativos en indicadores analíticos defendibles. Incluye un caso de incidencias de servicio, un ejemplo de SQL, técnicas para detectar sesgos y una forma de decidir cuándo una medida está suficientemente madura para incorporarse al trabajo habitual. El objetivo no es fabricar un panel vistoso: es conseguir que un número pueda explicarse, repetirse y utilizarse sin ocultar sus limitaciones.

Índice de contenidos

De los indicadores empresariales a los indicadores analíticos

En la gestión diaria, un indicador suele expresar una magnitud relevante: facturación mensual, presupuestos aceptados, incidencias abiertas o tiempo medio de respuesta. El primer problema consiste en escoger medidas que resulten útiles. El segundo, menos visible, consiste en demostrar que esas medidas representan de forma válida la realidad que se desea estudiar.

La primera cuestión se aborda al diseñar indicadores empresariales a partir de datos existentes. Aquí profundizaremos en la segunda: cómo construir una medición analítica a partir de registros concretos, con reglas de inclusión, versiones de los datos, controles de sesgo y comprobaciones reproducibles.

La distinción importa porque no todos los registros describen directamente el fenómeno que nos interesa. Un sistema de incidencias puede registrar una fecha de cierre, pero esa fecha no demuestra por sí sola que el problema quedara definitivamente resuelto. Una tienda puede registrar pedidos, pero contar pedidos no equivale necesariamente a contar compras pagadas. Una aplicación puede contar sesiones, pero una sesión no representa siempre una persona diferente.

La utilidad final se obtiene al conectar tres capas:

• Realidad operativa: el fenómeno que sucede fuera de la hoja de cálculo, como una incidencia efectivamente atendida.
• Representación en los datos: las filas, campos, fechas, estados y relaciones con los que ese fenómeno quedó registrado.
• Medición: la transformación documentada de esos registros en una cantidad comparable y accionable.

Si estas capas no se corresponden, un cálculo exacto puede describir algo distinto de lo que anuncia su nombre. Esa es una de las razones por las que la Ciencia de Datos exige conocimiento del proceso, y no solo destreza con fórmulas.

Comenzar por la decisión y la hipótesis

Un indicador debe nacer de una decisión posible, no de la curiosidad por explotar una columna disponible. Conviene escribir qué queremos averiguar, qué cambio sería relevante y quién podría actuar sobre el resultado.

Imaginemos una pequeña empresa que gestiona soporte técnico. Su responsable percibe que las incidencias tardan más en resolverse. Una pregunta vaga sería «¿trabajamos peor que antes?». Una pregunta analizable sería «¿ha disminuido el porcentaje de incidencias resueltas definitivamente en un máximo de 48 horas desde su apertura?».

La segunda pregunta introduce un resultado observable, una unidad de tiempo y una población que todavía habrá que delimitar. También permite proponer una hipótesis verificable: si las incidencias complejas han aumentado, quizá el indicador global cambie aunque el rendimiento dentro de cada tipo de incidencia permanezca estable.

Escribir primero la decisión prevista

Antes de recopilar más información, conviene registrar qué haríamos en cada escenario. Por ejemplo, si disminuye la resolución dentro del plazo y el deterioro se concentra en las incidencias complejas, podríamos revisar la asignación de especialistas. Si cae solo porque se han registrado incidencias todavía demasiado recientes, lo correcto sería corregir el cálculo, no reorganizar el equipo.

También debe quedar claro qué no permite decidir el indicador. Un aumento de la tasa de resolución en 48 horas no demuestra por sí solo mayor satisfacción del cliente, menos trabajo pendiente o menor coste. Esas hipótesis requieren otras evidencias.

Distinguir indicadores de resultado y de proceso

El porcentaje de incidencias resueltas en plazo describe un resultado. La antigüedad de la cola, las reasignaciones por incidencia o el tiempo hasta la primera intervención describen partes del proceso. Medir ambos niveles puede ayudar a investigar un cambio, pero no autoriza a asumir causalidad: que dos series evolucionen juntas no prueba que una explique la otra.

Si se necesitan criterios previos para decidir qué merece la pena medir, resulta complementaria la lectura sobre métricas empresariales útiles sin medir por medir.

Reconocer las huellas que dejan los sistemas existentes

Los datos operativos se diseñaron para que una aplicación funcione, no necesariamente para responder preguntas estadísticas. Por eso el trabajo inicial consiste en averiguar qué eventos registran los sistemas y qué sucesos quedan fuera.

Fuentes habituales y precauciones

• ERP y facturación: pedidos, líneas, abonos, cobros y fechas. Hay que distinguir creación, confirmación, entrega y pago.
• CRM: contactos, oportunidades y cambios de estado. Las oportunidades duplicadas y los estados antiguos pueden alterar las tasas.
• Soporte: aperturas, cierres, reaperturas, prioridad y reasignaciones. Los cambios de estado necesitan interpretación temporal.
• Registros de aplicaciones: eventos técnicos, errores y tiempos. Un reintento automático puede producir varios registros para una sola operación.
• Hojas de cálculo: tareas, fechas e importes. Conviene descubrir fórmulas manuales, filas sobrescritas y convenciones no documentadas.

La pregunta «¿de dónde sale cada dato?» debe ir acompañada por otras: ¿quién lo introduce?, ¿en qué momento?, ¿se puede modificar?, ¿se conserva el histórico?, ¿hay procesos que nunca se registran? Una empresa que empezó a digitalizar incidencias hace tres meses no puede comparar ese registro directamente con el de un año anterior sin explicar qué sucedía entonces con las incidencias atendidas por teléfono.

Cuando los datos proceden de varias aplicaciones, antes de combinarlos conviene revisar las reglas de identidad y las correspondencias entre campos. Para profundizar en esa cuestión está el artículo sobre integración de Ciencia de Datos con bases de datos empresariales.

Preferir hechos conservados a estados sobrescritos

Una tabla que contiene solamente el estado actual «cerrada» permite contar las incidencias cerradas ahora, pero puede no explicar cuándo pasaron por otros estados. Si necesitamos reconstruir una medición histórica, resulta más sólido disponer de un historial de eventos con identificador, instante, estado anterior y estado posterior.

No es imprescindible implantar un gran sistema de almacenamiento para empezar. Sí es necesario saber qué información histórica existe realmente. Reconstruir fechas inexistentes mediante suposiciones y presentarlas como hechos observados produce una falsa precisión.

Definir la unidad de observación y las relaciones

Antes de calcular una media o una tasa, debemos poder completar la frase: cada fila de mi tabla analítica representa exactamente…. Esa definición es el grano de los datos. Puede ser una incidencia, una llamada, una operación de cobro, una persona y mes, o un equipo y día.

Mezclar granularidades suele multiplicar registros de forma inadvertida. Supongamos que una incidencia contiene tres comentarios y dos asignaciones. Si unimos sin cuidado las tres tablas por identificador, podríamos producir seis filas para una sola incidencia. Un simple COUNT(*) contaría seis «incidencias» donde solo existía una.

Ejemplo de relaciones que pueden multiplicar filas

Si queremos medir incidencias, los comentarios deben agregarse por incidencia antes de incorporarlos como una característica, por ejemplo «número de comentarios». Si queremos medir transiciones, la unidad cambia y también cambian las preguntas que podemos responder.

Los identificadores únicos, las relaciones entre tablas y las reglas de deduplicación deben formar parte de la especificación. Aplicar DISTINCT al final sin entender el origen de la multiplicación puede ocultar duplicados verdaderos o eliminar observaciones legítimas.

Delimitar población, elegibilidad y denominador

El denominador es una decisión metodológica. Si queremos calcular la proporción de incidencias resueltas dentro de 48 horas, no sirve dividir entre todos los tickets que aparecen en pantalla. Debemos establecer cuáles pertenecen a la población estudiada y cuáles han tenido tiempo suficiente para alcanzar el resultado.

Definir inclusión y exclusión sin elegir el resultado

Para el ejemplo podemos incluir todas las incidencias reales abiertas en un periodo, independientemente de su situación final. Podríamos excluir registros de prueba o anulaciones administrativas si esa regla se fijó de antemano y está sustentada por campos verificables. No sería válido excluir las incidencias aún abiertas simplemente porque empeoran el porcentaje.

Una especificación útil debe responder a estas preguntas:

• ¿Quién o qué puede entrar en la población?
• ¿Qué fecha determina la pertenencia al periodo?
• ¿Cuándo se considera que una observación ha madurado?
• ¿Qué operaciones de prueba, duplicadas o anuladas quedan fuera y por qué?
• ¿Qué hacemos con valores ausentes o contradictorios?
• ¿Quién aprueba los cambios posteriores de las reglas?

Construir tasas sobre una población expuesta

Para medir incidencias por cada cien servicios, el denominador suele ser el número de servicios expuestos a la posibilidad de sufrirlas, no los clientes registrados desde el origen del negocio. Para calcular cancelaciones por pedido, el denominador debe incluir pedidos que realmente pudieron cancelarse, conforme a una definición explícita.

Las cantidades absolutas y las tasas aportan información distinta. Cien incidencias pueden representar una mejora si los servicios prestados se han cuadruplicado, o un deterioro si la actividad cayó a la mitad. Por tanto, conviene conservar y mostrar por separado numerador y denominador, además del porcentaje final.

Resolver la dimensión temporal antes de calcular

Los errores temporales son especialmente peligrosos porque generan series aparentemente coherentes. En un mismo registro pueden convivir la fecha del suceso, la de su anotación, la última modificación y la fecha en que se extrajo la información. Cada una responde a una pregunta diferente.

Tiempo del evento, del registro y del análisis

• Tiempo del evento: momento en el que sucedió la apertura, el cobro o el cierre.
• Tiempo de registro: instante en el que un sistema incorporó el dato, que puede ser posterior.
• Fecha de corte: momento hasta el cual admitimos información para un cálculo concreto.
• Periodo analizado: semana, mes o ventana de observación a la que asignamos el resultado.

Por ejemplo, una incidencia abierta el lunes a las 15:00 no puede clasificarse de manera definitiva como «no resuelta dentro de 48 horas» el mismo lunes a las 16:00. Solo ha transcurrido una hora. Incluirla como incumplimiento penalizaría artificialmente los días más recientes.

Cohortes y observaciones maduras

Una cohorte reúne elementos que comparten un instante o periodo de entrada: incidencias abiertas la misma semana, pedidos recibidos en un mes o equipos instalados durante un trimestre. Las cohortes permiten evaluar resultados desde un origen comparable.

Si la regla es «resuelta dentro de 48 horas», una incidencia solo puede clasificarse definitivamente cuando han pasado 48 horas desde la apertura, salvo que ya haya alcanzado antes un éxito que no pueda revertirse según la definición. En la práctica, el método más sencillo y conservador consiste en calcular únicamente incidencias cuya apertura sea anterior o igual a la fecha de corte menos 48 horas.

Las incidencias de ese conjunto que sigan abiertas al vencer su plazo cuentan como incumplimiento, no desaparecen del denominador. Las más recientes quedan pendientes de maduración y deben informarse por separado.

Registros tardíos, reaperturas y correcciones

Una incidencia podría registrarse un día después de producirse; otra podría reabrirse tras un cierre provisional. Si el objetivo es «resolución definitiva», no basta con la primera fecha de cierre. Hará falta un historial de transiciones o una definición operativa que indique cuándo un cierre es definitivo.

Conviene publicar además la fecha de corte del conjunto de datos. Si un cierre se comunica con retraso, un indicador del pasado puede cambiar tras una nueva extracción. Esto no es necesariamente un error, pero exige distinguir entre resultados provisionales y resultados consolidados, y conservar versiones cuando el histórico importe.

Fechas y husos horarios

En sistemas que combinan servidores, empleados o clientes de distintas ubicaciones, los instantes deben almacenarse e interpretarse con una política consistente de zona horaria. Sumar 48 horas transcurridas no es lo mismo que sumar dos días naturales o «dos días laborables». La medida debe declarar qué convenio aplica, especialmente si hay fines de semana o cambios de hora.

Construir una tabla analítica trazable

Una buena estrategia consiste en separar los datos originales de una tabla derivada preparada para el análisis. Esta tabla, también llamada dataset analítico, contiene una fila por unidad de observación, los campos necesarios y las reglas transformadas en variables comprensibles.

Ejemplo de estructura mínima para incidencias

Si la fuente no conserva una resolución definitiva y solo ofrece la primera fecha de cierre, el nombre de la medida debe reflejar esa realidad. Cambiar la etiqueta sin cambiar los datos no convierte un cierre provisional en resolución definitiva.

Crear variables derivadas sin perder el origen

Las variables calculadas pueden incluir antigüedad, elegibilidad, horas hasta la resolución, éxito dentro del plazo y periodo de apertura. Es recomendable mantener las fechas originales y generar los campos derivados mediante consultas o scripts versionados, en lugar de sobrescribirlos.

Una tabla de análisis es una representación temporal y técnica. No sustituye al sistema transaccional, y conviene controlar los permisos, la retención y la minimización de datos personales. Para evaluar tiempos y estados normalmente no hace falta copiar nombres, teléfonos, direcciones ni textos libres de las incidencias si un identificador seudonimizado basta.

El contrato mínimo del conjunto de datos

Documenta fuente, responsable, granularidad, claves, filtros, columnas, tipos, periodicidad de actualización, fecha de corte, transformaciones, tratamiento de ausentes y pruebas de calidad. Esa documentación permite que otra persona reproduzca la medición y detecte si una modificación del sistema ha cambiado su significado.

Elegir el tipo de indicador apropiado

Los datos existentes permiten construir medidas diferentes. Elegir la forma matemática depende del fenómeno, no de la apariencia que queramos dar al gráfico.

Conteos, proporciones y tasas de actividad

Un conteo responde «¿cuántos?»: 120 incidencias recibidas. Una proporción responde «¿qué parte de un conjunto?»: 84 incidencias resueltas dentro de plazo entre 120 elegibles, es decir, el 70 %. Una tasa normalizada puede responder «¿con qué frecuencia por unidad de exposición?»: 6 incidencias por cada 1.000 operaciones.

Una proporción está acotada entre 0 y 100 % si el numerador es un subconjunto del denominador. Una tasa por unidad de tiempo o exposición puede superar 100 % según la definición. Confundirlas suele provocar interpretaciones incorrectas.

Duraciones y distribuciones

La duración media es sensible a valores extremos. Si nueve trabajos duran una hora y uno dura 31 horas, la media es cuatro horas, pero nueve de los diez se completaron en una hora. Según la decisión, resultarán más útiles la mediana, los percentiles o el porcentaje bajo un umbral.

La mediana divide las observaciones ordenadas en dos partes; un percentil alto, como el 90, ayuda a describir la cola de duraciones, aunque su precisión depende de la muestra y del procedimiento de cálculo. Un indicador de «dentro de 48 horas» expresa cumplimiento del umbral; no sustituye por sí solo la distribución completa.

Indicadores adelantados y rezagados

Algunas variables se observan pronto y podrían anticipar problemas: crecimiento de la cola, acumulación de tareas sin asignar o descenso de primeras respuestas. Otras describen un resultado ya ocurrido: cancelaciones finales o cumplimiento del plazo. Llamar a una variable «predictiva» requiere comprobar empíricamente su capacidad de anticipación; una correlación retrospectiva no basta.

Indicadores compuestos: prudencia con los índices

Combinar calidad, rapidez y coste en una sola puntuación puede ser cómodo, pero exige decidir cómo normalizar escalas y justificar los pesos. Si una mala puntuación de seguridad puede quedar compensada por la rapidez, el índice quizá esté ocultando un riesgo no negociable. En muchas microempresas conviene comenzar con dos o tres medidas independientes antes de inventar una puntuación global.

Caso práctico: resolución de incidencias en 48 horas

Supongamos una empresa que registra cada incidencia con un identificador, fecha de apertura, fecha de resolución definitiva y categoría de complejidad. Quiere evaluar la proporción de incidencias resueltas definitivamente en las primeras 48 horas desde su apertura.

Se establece una regla operativa: solo entran incidencias reales abiertas en el periodo estudiado y cuya apertura ocurrió, al menos, 48 horas antes de la fecha de corte. Las incidencias abiertas que ya han superado las 48 horas se consideran incumplimientos. Los registros de prueba se excluyen mediante un campo explícito y auditable.

Definición de la medida

Numerador: incidencias elegibles con resolución definitiva válida no posterior a las 48 horas transcurridas desde su apertura.

Denominador: todas las incidencias elegibles de la cohorte que han tenido una ventana completa de 48 horas para alcanzar ese resultado, incluidas las que siguen abiertas.

Indicador: numerador dividido por denominador, multiplicado por cien. Si el denominador es cero, el resultado se declara «no calculable», nunca «0 %».

Primer cálculo ilustrativo

En una semana completamente observada se registraron 80 incidencias elegibles y 48 alcanzaron una resolución definitiva dentro del plazo. El indicador fue 48/80 × 100 = 60 %. En otra semana comparable se registraron 100, de las que 79 cumplieron el plazo: 79/100 × 100 = 79 %.

La lectura inmediata podría ser «la resolución ha mejorado 19 puntos porcentuales». El cálculo agregado es correcto, pero todavía no sabemos si el equipo resolvió cada tipo de incidencia con mayor eficacia o si atendió una mezcla más sencilla de problemas. Más adelante comprobaremos por qué esa diferencia importa.

Cuándo este cálculo no sería válido

Sería incorrecto usar «incidencias cerradas durante la semana» como numerador y «incidencias abiertas durante la semana» como denominador: ambas cifras pueden pertenecer a poblaciones distintas. También sería incorrecto tratar como fracaso inmediato las incidencias abiertas hace pocos minutos. Y si las incidencias reabiertas se consideran aún no resueltas definitivamente, habría que reconstruir su cierre final a partir del historial, no reutilizar cualquier fecha de cierre.

El ejemplo muestra una idea central: una fórmula sencilla puede exigir una definición de datos exigente.

Ejemplo de cálculo reproducible mediante SQL

Cuando los datos se encuentran en una base de datos, SQL permite fijar las condiciones de cálculo y ejecutarlas de forma repetible. El siguiente ejemplo utiliza sintaxis de PostgreSQL y presupone una tabla llamada incidencias con los campos id_incidencia, fecha_apertura, fecha_resolucion_definitiva y es_prueba. Cada fila representa una incidencia única y las fechas se expresan bajo una convención temporal consistente.

La consulta agrupa por semana de apertura, aplica una única fecha de corte y no elimina del denominador los casos sin resolución:

WITH parametros AS (
    SELECT TIMESTAMP '2026-10-20 12:00:00' AS fecha_corte
),
cohorte_madura AS (
    SELECT
        i.id_incidencia,
        i.fecha_apertura,
        i.fecha_resolucion_definitiva
    FROM incidencias AS i
    CROSS JOIN parametros AS p
    WHERE i.es_prueba = FALSE
      AND i.fecha_apertura IS NOT NULL
      AND i.fecha_apertura <= p.fecha_corte - INTERVAL '48 hours'
      AND i.fecha_apertura <= p.fecha_corte
),
resultados AS (
    SELECT
        DATE_TRUNC('week', fecha_apertura) AS semana_apertura,
        COUNT(*) AS total_elegibles,
        COUNT(*) FILTER (
            WHERE fecha_resolucion_definitiva IS NOT NULL
              AND fecha_resolucion_definitiva >= fecha_apertura
              AND fecha_resolucion_definitiva
                    <= fecha_apertura + INTERVAL '48 hours'
        ) AS resueltas_en_plazo
    FROM cohorte_madura
    GROUP BY DATE_TRUNC('week', fecha_apertura)
)
SELECT
    semana_apertura,
    total_elegibles,
    resueltas_en_plazo,
    ROUND(
        100.0 * resueltas_en_plazo
        / NULLIF(total_elegibles, 0),
        1
    ) AS porcentaje_en_48_horas
FROM resultados
ORDER BY semana_apertura;

El ejemplo presupone que fecha_resolucion_definitiva procede de una reconstrucción fiable del proceso. También presupone que los datos disponibles en la extracción son los conocidos a la fecha de corte; si existen anotaciones retroactivas, deben tratarse con una política de revisiones o con un histórico de datos «tal como se conocían entonces». La consulta no reconstruye por sí sola esos estados históricos.

En un entorno real suele convenir limitar el rango de fechas analizado, definir expresamente la zona horaria y emplear tipos de fecha compatibles con esa política, por ejemplo timestamptz en PostgreSQL. La misma lógica puede trasladarse a otro motor adaptando sus funciones de fecha y agregación.

Comprobaciones antes de confiar en la consulta

Una consulta que devuelve una tabla sin errores no está necesariamente bien diseñada. Conviene probarla con un conjunto pequeño de casos cuyo resultado sea conocido:

• Una incidencia cerrada exactamente a las 48 horas debe contar como éxito si el límite es inclusivo.
• Una cerrada a las 48 horas y un minuto debe contar como incumplimiento.
• Una todavía abierta después de 48 horas debe permanecer en el denominador.
• Una abierta hace solo una hora debe quedar pendiente de maduración.
• Una fecha de resolución anterior a la apertura debe producir una alerta de calidad y no un éxito.
• Un identificador duplicado debe detectarse antes de ejecutar el cálculo definitivo.

Si el sistema gestiona resoluciones provisionales y reaperturas, estas pruebas deben ampliarse a trayectorias de estado completas. La lógica temporal es parte del indicador, no un detalle secundario de programación.

Detectar cambios de composición y conclusiones engañosas

Volvamos al ejemplo de las dos semanas. Sus valores globales pasaron del 60 al 79 %. Parece una mejora importante. Pero el análisis por complejidad muestra una realidad diferente.

En ambos tipos de incidencia el cumplimiento empeoró: de 90 a 87,5 % en las sencillas y de 50 a 45 % en las complejas. Sin embargo, el total mejoró porque en la semana B hubo muchas más incidencias sencillas, que habitualmente se resuelven antes. Este fenómeno ilustra cómo un cambio de composición puede invertir la conclusión que parece sugerir un agregado; es un caso de la conocida paradoja de Simpson.

Comparar con una composición de referencia

Una forma de investigar el efecto consiste en calcular qué resultado tendría cada semana si ambas compartieran la misma distribución de tipos. Si tomamos como referencia una población compuesta por 50 % de incidencias sencillas y 50 % de complejas, obtenemos:

• Semana A: (90 % × 0,5) + (50 % × 0,5) = 70 %.
• Semana B: (87,5 % × 0,5) + (45 % × 0,5) = 66,25 %.

Esta estandarización es un cálculo ilustrativo, no una corrección universal. Requiere categorías estables y una población de referencia justificada. Su valor es demostrar que la mejora agregada puede proceder del cambio de mezcla y no del desempeño de cada grupo.

Segmentar sin fabricar conclusiones

La segmentación debe estar vinculada a mecanismos plausibles: complejidad, tipo de servicio, canal de entrada o equipo responsable, por ejemplo. Dividir una muestra pequeña en decenas de categorías crea porcentajes frágiles. Además, conviene evitar conclusiones sobre colectivos que no estén suficientemente representados.

No toda diferencia por segmento es atribuible al segmento. Una categoría puede reunir clientes con distintas necesidades o incidencias de distinta antigüedad. Cuando una comparación tenga consecuencias importantes, será necesario profundizar con análisis estadístico, revisión del proceso o experimentación apropiada.

Interpretar volumen, variabilidad e incertidumbre

Dos porcentajes idénticos no aportan el mismo nivel de evidencia si uno procede de diez observaciones y el otro de diez mil. Un 80 % obtenido con ocho éxitos entre diez casos es mucho más sensible a un caso adicional que un 80 % obtenido con ocho mil éxitos entre diez mil.

Mostrar siempre la base de cálculo

Es preferible comunicar «80 % (8 de 10)» que escribir simplemente «80 %». El denominador permite evaluar la escala del fenómeno y apreciar cuándo una aparente subida o bajada podría depender de muy pocos registros.

No confundir variación con tendencia

Comparar dos semanas puede ser útil para detectar una señal, pero no basta siempre para afirmar que existe una tendencia sostenible. Las series deben examinarse con varias observaciones, posibles efectos estacionales, días laborables, festivos, cambios de proceso y tamaño de las cohortes. Una media móvil puede suavizar oscilaciones; también puede ocultar cambios bruscos si se utiliza sin mostrar los datos originales.

Intervalos de confianza y límites de interpretación

Cuando se estima una proporción a partir de una muestra de una población más amplia, un intervalo de confianza puede expresar la incertidumbre de muestreo bajo determinados supuestos. Su anchura depende, entre otras cosas, del tamaño muestral y de la variabilidad observada. No elimina sesgos de selección, errores de registro ni cambios de definiciones.

Si el indicador describe exhaustivamente todos los casos de una semana, el porcentaje de esa semana no tiene incertidumbre de muestreo sobre esos casos. Sin embargo, sí puede haber incertidumbre sobre lo que sucederá en semanas futuras o sobre si las comparaciones representan una mejora persistente. Conviene distinguir ambos problemas antes de añadir barras de error.

Umbrales prácticos, no falsa exactitud

Un cambio de 78,8 a 79,1 % no merece necesariamente una decisión diferente. La precisión presentada debe corresponderse con el volumen y la calidad de los datos. Resulta útil definir de antemano qué magnitud de cambio es operativamente relevante y qué evidencias adicionales se solicitarán antes de intervenir.

Medir la calidad de los propios datos

Un indicador de resultado necesita controles sobre el conjunto de datos que lo alimenta. Si solo miramos la cifra final, podemos confundir una mejora del negocio con una pérdida de registros o una modificación silenciosa de una aplicación.

Controles mínimos recomendables

Por ejemplo, si el 12 % de las incidencias no tiene fecha de apertura, calcular una tasa sobre el 88 % restante puede producir una cifra útil únicamente si las ausencias no introducen un sesgo material. Ese supuesto debe investigarse; no puede darse por cierto automáticamente.

Los ausentes no son ceros

Una fecha de cierre vacía puede significar «sigue abierta», «aún no se ha sincronizado» o «falló el registro». Tratar los tres casos como equivalentes puede falsear un indicador. La interpretación correcta requiere consultar las reglas del sistema y, en ocasiones, incorporar otra tabla de estados.

Conviene registrar los errores y la evolución de su frecuencia. Para ampliar los controles operativos pueden consultarse los artículos sobre limpieza de datos antes del análisis y detección de errores frecuentes en datos empresariales.

Indicadores de calidad paralelos

Una opción especialmente útil es acompañar la cifra principal con medidas como porcentaje de registros con fecha válida, cantidad de duplicados detectados, casos pendientes de maduración y antigüedad de la última extracción. Estas cifras no son decorativas: ayudan a decidir si el resultado principal merece confianza ese día.

Validar un indicador antes de utilizarlo

La validación no consiste en comprobar que el gráfico se dibuja correctamente. Consiste en demostrar que la implementación respeta la definición y que el resultado ofrece una representación razonable del fenómeno.

1. Validación técnica

Revisar tipos de datos, claves únicas, fechas imposibles, filtros, nulos y relaciones entre tablas. La suma de los segmentos debe coincidir con el total cuando se trata de una partición completa y no solapada. En el ejemplo, sencillas más complejas deben reproducir los recuentos globales de cada semana.

2. Validación de cálculo

Seleccionar casos conocidos y resolverlos manualmente. Conviene incorporar pruebas de límites: cierre exactamente a 48 horas, cierre posterior, caso abierto y caso aún inmaduro. Si existen reglas de calendario laboral, también deben probarse fines de semana y cambios de hora.

3. Validación operativa

Contrastar una muestra con las personas que conocen el proceso. Si una incidencia figura cerrada pero continúa requiriendo intervención, la cifra puede estar midiendo cierres administrativos y no resoluciones reales. El desacuerdo entre datos y experiencia operativa es una oportunidad de investigar, no una razón para descartar automáticamente uno de los dos.

4. Validación histórica

Recalcular periodos anteriores con la misma versión de reglas. Buscar saltos coincidentes con migraciones, cambios de aplicación o nuevas políticas de registro. Cuando se modifica la fórmula, documentar si las series históricas se recalculan o si se publican versiones incompatibles.

5. Validación de utilidad

La pregunta final es sencilla: ¿este indicador ayuda a distinguir decisiones diferentes? Si una cifra varía de forma continua, pero nunca afecta a una revisión, una prioridad o una hipótesis de trabajo, quizá no necesita formar parte del seguimiento permanente.

En proyectos con varios responsables resulta especialmente conveniente conservar estas evidencias en una documentación compartida. El artículo sobre documentación de proyectos de Ciencia de Datos desarrolla ese ámbito con mayor amplitud.

Poner el indicador en producción sin perder su significado

La primera versión puede calcularse con una hoja de cálculo o una consulta manual. Si se utiliza regularmente, conviene convertirla en un proceso repetible con responsables, controles y trazabilidad. Automatizar una medida que todavía cambia de definición suele multiplicar los problemas.

Ficha técnica mínima del indicador

La ficha debería incluir además propietario, responsable técnico, ubicación de la consulta o script, número de versión y fecha del último cambio. Si una columna deja de existir o un sistema modifica el significado de «cerrada», debe existir una vía clara para revisar el indicador.

Separar cálculo, visualización e interpretación

Es preferible generar un conjunto de resultados controlado y utilizarlo después en tablas o gráficos, en lugar de esconder toda la lógica en fórmulas repartidas por un panel. El cálculo queda más fácil de revisar; la visualización puede cambiar sin alterar el método.

Un gráfico debería mostrar denominadores relevantes, unidades, periodo y fecha de actualización. Para comunicar conclusiones a responsables no técnicos, es útil separar dato observado, interpretación plausible y decisión propuesta. El artículo sobre presentación de resultados de Ciencia de Datos a directivos desarrolla esta última fase.

Alertas y revisiones

Las alertas pueden activarse ante cambios relevantes en el indicador o en sus controles de calidad. No obstante, un porcentaje fuera de rango no debería desencadenar por defecto acciones irreversibles. En procesos importantes conviene exigir revisión de contexto, volumen suficiente y comprobación de posibles incidentes de datos.

Una solución sostenible debe permitir volver a ejecutar los cálculos, auditar sus cambios y sustituir las herramientas sin perder las definiciones. Este enfoque también facilita que el proyecto crezca, como se explica en el diseño de proyectos de Ciencia de Datos preparados para crecer.

Errores que conviene evitar

Muchos indicadores fracasan sin que exista un fallo visible en sus fórmulas. El problema suele aparecer en las premisas que se dieron por válidas.

Elegir la columna disponible en lugar del fenómeno real

«Fecha de cierre» no siempre equivale a «fecha de resolución». «Usuarios registrados» no siempre equivale a «usuarios activos». Es necesario conocer el proceso que genera el dato antes de bautizar el indicador.

Combinar poblaciones distintas

Dividir cierres de una semana entre aperturas de esa misma semana mezcla cohortes y puede producir tasas que aparentan mejoras o deterioros inexistentes. Numerador y denominador deben corresponder a un universo claramente definido.

Descartar los casos incómodos

Excluir incidencias abiertas, transacciones fallidas o registros sin resultado puede introducir sesgo de supervivencia o selección. Si hay casos pendientes de observación, deben tratarse conforme a una regla temporal explícita, no desaparecer silenciosamente.

Confundir cambios de mezcla con mejora de rendimiento

Una tasa agregada puede subir mientras cae en cada segmento, como mostró el ejemplo de complejidad. La comparación requiere comprender qué cambió en la composición de las observaciones.

Presentar muestras diminutas con excesivos decimales

Un 66,67 % basado en dos aciertos entre tres casos no tiene la misma estabilidad que un resultado semejante basado en miles. Publicar el denominador reduce el riesgo de interpretar como tendencia lo que solo es variabilidad.

Cambiar reglas sin actualizar el histórico

Si antes se contaba cualquier cierre y ahora solo la resolución definitiva, las cifras no son directamente comparables. Hay que recalcular los periodos o señalar dónde cambia la versión de la medida.

Confiar exclusivamente en un panel

La facilidad de lectura no sustituye a la validación. Un gráfico atractivo puede hacer más convincente un error sistemático. La presentación debe ser el último paso de una cadena de decisiones bien documentada.

Plan práctico para construir el primer indicador fiable

Una microempresa o un equipo pequeño puede aplicar este método sin contratar una infraestructura analítica compleja. Lo importante es mantener reducido el alcance y exigir claridad en las definiciones.

1. Escoger una decisión concreta. Por ejemplo, revisar la capacidad de resolver incidencias en un plazo de 48 horas.
2. Escribir una definición provisional. Precisar resultado, población, momento de entrada, fecha de corte y regla de elegibilidad.
3. Inventariar las fuentes. Localizar los registros que existen y comprobar cómo se generan sus fechas y estados.
4. Fijar el grano. Asegurar una observación única por incidencia y controlar las relaciones con tablas auxiliares.
5. Extraer una muestra verificable. Preparar casos variados: éxito, incumplimiento, abierto, inmaduro y registro incorrecto.
6. Preparar una tabla analítica. Conservar valores originales, añadir variables derivadas y documentar los filtros.
7. Construir el primer cálculo. Obtener numerador, denominador y porcentaje para periodos suficientemente maduros.
8. Revisar segmentos. Comprobar si un cambio global se explica por un cambio de composición.
9. Validar con operaciones reales. Contrastar casos individuales y resultados históricos con responsables del proceso.
10. Definir controles y responsables. Establecer revisiones de calidad, fecha de corte, versión y tratamiento de anomalías.
11. Automatizar cuando sea estable. Programar el cálculo solamente después de verificar que su definición produce resultados útiles.
12. Reevaluar su utilidad. Retirar, modificar o complementar el indicador si deja de representar la decisión original.

El resultado inicial no tiene por qué ser un cuadro de mando. Puede consistir en una tabla semanal con cinco columnas: periodo, casos elegibles, casos dentro del plazo, porcentaje y observaciones de calidad. Si la definición es sólida, esa tabla ya ofrece una base mucho más útil que decenas de gráficos sin contexto.

Preguntas frecuentes

Conclusión: un indicador útil debe resistir las preguntas difíciles

Construir indicadores útiles a partir de datos existentes no consiste únicamente en sumar, dividir o representar cifras. Consiste en relacionar una pregunta real con registros que tienen un origen, una estructura y unas limitaciones. Esa relación exige definir la unidad de observación, elegir una población válida, controlar el tiempo y conservar una transformación reproducible.

El caso de las incidencias mostró por qué un porcentaje global puede parecer favorable mientras el rendimiento empeora dentro de cada categoría. También mostró la importancia de no confundir incidencias aún recientes con incumplimientos, ni cierres administrativos con resoluciones definitivas. Estas distinciones son pequeñas en apariencia, pero determinan si el indicador merece confianza.

Para un profesional técnico, dominar este proceso significa poder explicar de dónde procede cada cifra y detectar sus puntos débiles. Para una microempresa, significa tomar decisiones con mejores fundamentos sin necesitar herramientas desproporcionadas. La medida verdaderamente útil no es la más sofisticada: es la que conserva su significado cuando alguien pregunta exactamente qué se contó, cuándo, por qué y con qué limitaciones.