Una fábrica pesa los residuos en el puente báscula. Otra fábrica lo estima según el volumen del contenedor. Ambas entregan una cifra para la misma línea del informe. Nadie ha mentido, nadie ha cometido un error. Simplemente nunca se ha establecido cuál es exactamente la definición de ese dato, y por eso cada unidad ha elegido la interpretación más lógica que tenía a su disposición.
Esto no es una excepción. Es el estado normal de una organización en la que la misma métrica es entregada por distintos equipos, con distintos sistemas de origen y distinto historial. La pregunta no es cómo eliminar esta diferencia antes de que surja. La pregunta es qué hace con ella en el momento en que la detecta.
El paso que suele omitirse es que la definición misma quede registrada en algún lugar. No en la cabeza del controller que lo hace así desde hace años, sino en un registro: este dato significa esto, se mide así, y estas unidades cuentan o no cuentan. Qué es un valor válido dentro de ese registro y quién lo detecta si una entrega queda fuera de él, se describe en la página sobre qué es un valor válido y quién lo detecta si algo sale mal. Sin ese registro, cada suma entre unidades es una suma de cosas que no son del todo iguales, envueltas en una cifra que aparenta ser inequívoca.
Este registro es precisamente el trabajo del Data Readiness Scan: no reescribir el informe, sino construir el registro de datos en el que, para cada dato, se indica qué es, de dónde procede y quién lo valida. Ese registro es el lugar donde la diferencia entre unidades se hace visible, en lugar de hacerse visible solo después de que la cifra ya se ha sumado.
Una vez que ve que la unidad A y la unidad B entienden algo distinto por el mismo dato, hay a grandes rasgos tres vías.
La primera es armonizar: imponer una única definición para toda la organización, con todos los ajustes de sistema que eso conlleva. Suele ser la vía correcta a largo plazo, pero no es algo que se resuelva de un día para otro.
La segunda es documentar y corregir: dejar la desviación donde está, pero registrar su magnitud y, mediante una conversión fija, asegurar que el total sea correcto. Esto funciona cuando la diferencia es estable y conocida — por ejemplo, cuando una sede utiliza de forma estructural otro método de medición que puede rastrearse.
La tercera es señalizar: no corregir, sino activar una alerta en cuanto una entrega se desvíe del patrón habitual de esa unidad. Cómo se configura una desviación de este tipo y quién recibe la notificación se detalla en la página sobre cómo configura una desviación de señal y quién lo detecta cuando ocurre. Esta vía no está pensada para resolver el problema, sino para evitar que pase desapercibido mientras se trabaja hacia una solución estructural.
Qué vía es la adecuada depende de cuántas unidades se desvían, de cuán estable es esa desviación y de cuánto tiempo queda antes de que la cifra entre en un periodo de reporte. Es una decisión que varía según la organización y que este registro no toma por usted — pero sí hace visible que esa decisión debe tomarse.
La diferencia de definición es uno de los errores más silenciosos que existen, porque cada unidad tiene razón por su cuenta. La sede que estima por volumen de contenedor no hace nada mal dentro de su propio proceso. El problema surge solo en el nivel donde las cifras se juntan, y precisamente ahí a menudo nadie está designado para comprobar si las definiciones subyacentes son siquiera comparables.
Por eso la titularidad por dato es tan importante como la definición misma. Qué controles corresponden a un dato y quién lo detecta si uno de esos controles se omite se describe en la página sobre qué controles corresponden a un dato y quién lo detecta si falta alguno. Sin un titular designado, la pregunta de "pero quién ve esto en realidad" queda sin respuesta, aunque la definición esté por escrito.
Resulta tentador querer resolver este problema con un sistema que normalice automáticamente las entregas. Pero una herramienta que se coloca sobre un conjunto de datos sin definir no normaliza nada — envuelve las mismas diferencias en una interfaz más ordenada. El orden que resiste es primero establecer la definición y la titularidad, y solo después ver qué sistema encaja con ello. Por qué ese orden no es casual se explica en la página sobre comprar primero una herramienta o organizar primero el proceso.
En cuanto queda establecido, por cada dato, cuál es la definición, quién es el titular y qué desviaciones se señalizan, surge otro tipo de pregunta: quién realizará el trabajo asociado a esos controles — el recálculo, la consulta a la unidad que se desvía, el mantenimiento del propio registro. Parte de ese trabajo es lo bastante repetible como para transferirlo a un paso automático; otra parte requiere un juicio que sigue correspondiendo a una persona. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte de ella puede asumir la IA, a partir del mismo tipo de concreción que este registro: no la pregunta de si la automatización es posible, sino qué parte de qué tarea le corresponde.
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.