Qué control corresponde a este punto de datos, y quién lo ve cuando el valor se desvía

Un punto de datos sin control es una cifra que nadie contradice. Aparece en el informe, procede de un sistema o una hoja de cálculo, y se acepta porque no hay motivo para cuestionarla. Solo cuando una parte externa plantea una pregunta, o cuando una cifra de repente varía por un factor de diez respecto al año anterior, se descubre que nadie la había revisado nunca. Entonces ya es demasiado tarde para reconstruir dónde se produjo el error.

La pregunta que evita esto es fácil de formular y difícil de responder sin estructura: qué control corresponde a este punto de datos, y quién lo detecta cuando algo va mal. Son dos preguntas, y ambas deberían tener respuesta antes de que una cifra entre en un informe.

Qué es un valor válido, y qué no lo es

Cada punto de datos tiene límites. Un consumo de energía no puede ser negativo. Un número de fte no es un decimal. Un porcentaje no supera el cien. Esto parece evidente, pero en la práctica estos límites no están registrados en ningún lugar: existen en la mente de quien lleva años procesando los datos, y desaparecen en cuanto esa persona cambia de puesto.

Registrar un valor válido no significa solo anotar un límite inferior y un límite superior. También significa fijar en qué unidad se entrega un punto de datos, qué formatos de fecha se permiten, y si un campo vacío es un resultado válido o una señal de que falta algo. Sin ese acuerdo, cada excepción se vuelve a evaluar, según quien la esté mirando en ese momento. Qué cuenta exactamente como válido, y cuándo un valor límite es más bien una suposición que una regla, se explica en la página sobre qué es un valor válido.

La diferencia entre un error y una señal

No toda desviación es un error. Un punto de datos puede estar completamente dentro de los límites válidos y, aun así, ser una señal: un consumo que baja de repente, una cantidad que es el triple que el trimestre anterior, un proveedor que por primera vez en dos años no entrega datos. Esos no son valores inválidos. Son valores que requieren la mirada de alguien que conoce el contexto.

Una regla de señal es, por tanto, algo distinto de una regla de validación. La validación determina si un valor puede existir. Una señal determina si un valor, aunque sea válido, sigue siendo motivo para revisarlo. Cómo se establece ese umbral —un porcentaje fijo de desviación, una comparación con una serie histórica, o una combinación— depende del punto de datos y de lo estable que sea normalmente la actividad subyacente. El diseño de una regla de este tipo, incluida la ponderación entre demasiadas y muy pocas señales, se describe en la página sobre cómo configurar una desviación de señal.

Quién lo detecta no es una cuestión técnica

Una regla que nadie ve no es una regla. Si un control de validación o de señal se activa en algún sistema, debe estar claro quién recibe la alerta y qué hace esa persona con ella. ¿Es el responsable de introducir los datos, el titular del punto de datos, o alguien que supervisa el conjunto antes de que se compile el informe? Sin un destinatario designado, una señal desaparece en un registro que nadie consulta.

Esto tiene que ver con la titularidad, y la titularidad se relaciona con un problema que en muchas organizaciones sigue sin resolverse: distintas unidades utilizan definiciones diferentes para lo que, sobre el papel, es el mismo punto de datos. Un centro cuenta los fte incluyendo la contratación externa, otro no. Cuando se activa una señal que indica que un valor se desvía, la primera pregunta no suele ser si el valor es correcto, sino si todos manejan la misma definición. Cómo abordar esto se explica en la página sobre qué hacer con definiciones que varían entre unidades.

Por qué esto no empieza con una herramienta

Resulta tentador buscar estos controles en un paquete de software: algo que avise, valide e informe automáticamente. Pero una herramienta que aplica controles sobre datos para los que nadie ha registrado qué es un valor válido no está realizando ningún control; solo produce un resultado que parece ordenado sobre un proceso que aún no se ha pensado bien. Las reglas deben existir primero, independientemente del sistema que finalmente las aplique. Este orden, y por qué invertirlo suele acabar en decepción, se explica en la página sobre comprar primero una herramienta o diseñar primero el proceso.

Qué se obtiene antes de construir nada

Cuando para cada punto de datos está establecido qué es un valor válido, cuándo se activa una señal, y quién recibe esa señal, se obtiene un registro que no solo documenta, sino que también sirve como conjunto de requisitos. Ese registro es exactamente lo que se necesita para determinar qué debe poder hacer un sistema —construido internamente o adquirido— más adelante. Sin ese conjunto de requisitos, cada adquisición se convierte en una apuesta. Cómo traducir esto en requisitos funcionales que surgen del propio proceso, en lugar de partir de un proveedor, se explica en la página sobre requisitos funcionales derivados de su propio proceso.