Una cifra en un informe de sostenibilidad casi siempre ha recorrido un camino. Empieza como una línea en una factura energética, un contador en un sistema de producción, un campo de entrada en una herramienta de RR. HH. Para el momento en que la cifra aparece en el informe, ha sido contada, convertida, agregada y en ocasiones corregida. Esos pasos intermedios rara vez son visibles en el resultado final. Quien solo mira el informe ve una cifra. Quien mira el camino recorrido ve una serie de decisiones.
Entre la fuente y el informe suele haber un orden fijo de operaciones, incluso cuando nadie lo ha puesto nunca por escrito.
Primero se recopilan los datos: se exportan de un sistema, se copian de una factura, se trasladan desde una hoja de cálculo. Después se normalizan: los litros se convierten en metros cúbicos, los kilovatios-hora en gigajulios, la moneda local en una unidad de cálculo fija. A continuación se asignan a una categoría o alcance, lo cual es una decisión y no un automatismo. Luego llega la agregación: las cifras de sedes, meses o departamentos se combinan en un total anual. Por el camino se producen correcciones, por dobles conteos, por meses faltantes, por una unidad errónea que alguien detectó hace un año y corrigió manualmente.
Cada paso es un lugar donde se hace una suposición. Se elige un factor de emisión. Una estimación sustituye a una medición ausente. Se aplica un redondeo. Nada de eso es, en sí mismo, un problema. El problema surge cuando ya nadie sabe qué suposición se hizo, quién la hizo y por qué.
Una cifra de informe que no se puede rastrear hasta su fuente es una cifra afirmada. En el momento en que un controller, un auditor o un supervisor pregunta cómo se compuso una cifra, la respuesta debe ser algo más que "eso está en el sistema". La respuesta debe poder mostrar la ruta: esta fuente, esta conversión, esta agregación, esta corrección.
Registrar esa ruta tiene tres consecuencias directas. En primer lugar, detectar errores se convierte en un trabajo de minutos en lugar de días, porque queda claro dónde se aplicó una conversión y dónde no. En segundo lugar, se hace posible el traspaso: si la persona que gestiona la hoja de cálculo se marcha, el conocimiento sobre las operaciones no se va con ella. En tercer lugar, se crea una base para la verificación, porque una parte externa puede seguir los pasos sin tener que reconstruirlos primero.
Sin ese registro, cada ciclo de informes es una repetición de trabajo de investigación. Alguien llama al anterior responsable, busca en correos antiguos, adivina la razón detrás de un redondeo. Ese trabajo es invisible en el propio informe, pero determina cuánta confianza merece ese informe.
No todas las operaciones requieren el mismo enfoque. La agregación, en la que se combinan cifras de varias fuentes en un único total, requiere un registro distinto al de la normalización, en la que se homogeneizan unidades y definiciones. Quien quiera saber cómo documentar exactamente la agregación lo encuentra en una explicación sobre cómo registrar los pasos de agregación, y quien se pregunte cómo tratar la normalización puede leerlo en una descripción sobre cómo registrar la normalización. Ambas forman parte de la misma cadena, pero las preguntas que plantean son distintas: la agregación plantea preguntas sobre integridad, la normalización sobre coherencia.
La situación también cambia cuando la propia fuente no es un sistema sino una hoja de cálculo. En ese caso no hay exportación automática, ni registro de sistema, ni estructura fija, y el registro debe construirse de otra manera. Quien se enfrenta a esa situación encuentra puntos de partida en una explicación sobre el mapeo de fuente a informe cuando la fuente es una hoja de cálculo y en un resumen de las operaciones entre la fuente y el informe específicamente en fuentes de hoja de cálculo. Para quien no dispone de presupuesto para una herramienta y debe construir el linaje con los medios ya disponibles, hay un método para crear linaje sin software especializado.
El registro de operaciones a menudo se confunde con un registro de cambios: una lista de quién modificó qué y cuándo. Eso es parte de la historia, pero no la historia completa. Una pista de auditoría que solo registra modificaciones no explica por qué se tomó una decisión ni qué regla se aplicó. La diferencia entre un registro de cambios y una verdadera estructura de rendición de cuentas se desarrolla en una exposición sobre por qué una pista de auditoría debe ser más que un registro de cambios.
El Data Readiness Scan traza esta ruta: qué fuente alimenta qué dato, qué operaciones hay entre medias, quién es responsable de cada paso y qué regla de calidad corresponde a cada uno. No es un informe ni un cuestionario, sino la estructura subyacente que hace que ambos sean fiables.
En cuanto se describen las operaciones entre la fuente y el informe, se hace visible qué pasos son trabajo manual fijo: transcribir una factura, aplicar un factor de conversión fijo, combinar cifras mensuales según una regla fija. Ese es precisamente el tipo de trabajo del que se puede calcular qué parte puede asumir la IA, sin que el registro de fuente a informe pierda su función. FTE TO AI calcula por tarea qué parte de ella es transferible, a partir del escaneo de trabajo que hace visible esa diferencia por tarea.
El Data Readiness Scan está en desarrollo. Quien desee que las operaciones entre la fuente y el informe queden registradas en cuanto el escaneo esté disponible puede inscribirse en la lista de espera.
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.