Una desviación de señal —a veces llamada regla de validación o valor umbral— es una regla que hace que un sistema controle si un valor introducido se encuentra dentro de un rango esperado. Suena técnico, pero la pregunta subyacente es simple: qué es un valor válido para este punto de datos, y qué ocurre si ese valor se encuentra fuera de ese rango. Sin respuesta a esas dos preguntas, una desviación de señal es una configuración sin función.
Una desviación de señal consta de tres partes. En primer lugar, un límite: un mínimo, un máximo, o una relación esperada entre dos puntos de datos, como el consumo energético por metro cuadrado que no puede desviarse en un factor de diez respecto al año anterior. En segundo lugar, una acción: qué hace el sistema cuando se supera ese límite —una notificación, un bloqueo, o nada. En tercer lugar, un destinatario: quién ve esa notificación, y si esa persona sabe qué se espera de ella cuando la ve.
La mayoría de las organizaciones que empiezan con desviaciones de señal se centran en la primera parte y se olvidan de la tercera. Se configura un valor umbral, el sistema genera una notificación, y esa notificación desaparece en la bandeja de entrada de alguien que ya no trabaja en la organización o que no sabe que esto forma parte de sus tareas. La regla existe, pero nadie se da cuenta cuando se activa.
El límite que establece depende del propio punto de datos y de lo que ya sabe sobre él. Para algunos puntos de datos, un valor válido es fácil de determinar: un porcentaje no puede superar cien, una cantidad de residuos no puede ser negativa. Para otros puntos de datos, el límite es menos fijo y más una cuestión de experiencia: una emisión de CO2 por sede que este año es tres veces superior a la del año anterior no es por definición incorrecta, pero sí vale la pena revisarla antes de que la cifra continúe su curso. Qué es exactamente un valor válido para un punto de datos dado se describe en la página qué es un valor válido, donde se distingue entre límites estrictos y señalización basada en desviación.
Esa distinción es importante porque determina cuál debe ser la acción. Un límite estricto —un porcentaje superior a cien— puede bloquear una entrada. Una señalización basada en desviación —una cifra de emisión que llama la atención pero no es por definición errónea— no puede ser un bloqueo, ya que eso impediría injustamente valores correctos pero inusuales. Aquí corresponde una notificación a una persona que pueda evaluar si la desviación es un error o un cambio real.
La tercera pregunta —quién lo ve cuando algo va mal— no es una configuración técnica sino una cuestión de propiedad. Una desviación de señal sin destinatario asignado no funciona, aunque la regla esté configurada correctamente. Esto se relaciona con la pregunta de qué controles corresponden a un punto de datos y quién debe ser informado de ello, un tema que se desarrolla más ampliamente en la página qué controles corresponden a un punto de datos y quién se entera de ello.
En la práctica, el destinatario suele ser quien ha aportado el punto de datos, pero esa no siempre es la elección correcta. Quien ha aportado la cifra no es automáticamente quien puede evaluar si una desviación es correcta —eso a menudo requiere a alguien con conocimiento de la fuente subyacente o de cifras comparables de años anteriores. Quién puede realizar esa evaluación varía según la organización y según el punto de datos, y precisamente por eso la propiedad debe establecerse por punto de datos en lugar de suponerse.
Una configuración para una desviación de señal se hace rápidamente en un sistema. La tentación es entonces grande de pensar que el problema queda resuelto con ello. Pero una herramienta que señala sin que haya un proceso establecido detrás —quién recibe la notificación, qué debe hacer, en qué plazo— solo da la apariencia de control. Esta es la misma trampa que se describe en la página comprar primero una herramienta o diseñar primero el proceso: un sistema sobre un proceso desorganizado genera notificaciones que nadie atiende, lo que en un informe se ve aún más tranquilo que la ausencia de notificaciones, pero en la práctica no cambia nada respecto a la fiabilidad de la cifra subyacente.
Una desviación de señal solo tiene sentido, por lo tanto, cuando las tres partes están asignadas conjuntamente: un límite adecuado al punto de datos, una acción adecuada al tipo de desviación, y un destinatario que sabe qué debe hacer. No es una configuración que se completa en una hora para cien puntos de datos. Es una elección que se hace por punto de datos, basada en lo que ya se sabe sobre la fuente y el historial de la cifra.
Si una tarea como evaluar una desviación señalada es adecuada para automatizar, o si esa evaluación sigue siendo trabajo humano, es una pregunta que varía según la tarea. El [escáner de trabajo](https://fte-to-ai.nl) de FTE TO AI calcula por tarea qué parte del trabajo puede asumir la IA, y qué parte sigue requiriendo la evaluación de alguien que conozca el contexto del punto de datos.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.