El sector del transporte tiene una característica que pocos otros sectores comparten: la mayor parte de las emisiones de CO2 se genera fuera de la oficina, repartida entre vehículos, trayectos y subcontratistas que no todos utilizan el mismo sistema. Mientras que un edificio de oficinas es relativamente fácil de medir, el parque de vehículos de una empresa de transporte consta de decenas o cientos de fuentes móviles individuales, cada una con su propio consumo de combustible, grado de carga y ruta. Las emisiones no residen en un edificio sino en una suma de trayectos, y esa suma debe proceder de varios sistemas a la vez.
A esto se añade una segunda capa: una parte considerable de los kilómetros a menudo no la recorre el parque de vehículos propio, sino subcontratistas, transportistas contratados o socios de la cadena. En la mayoría de los casos, esas emisiones caen dentro del alcance 3, y los datos correspondientes rara vez están disponibles de forma estándar. Una empresa de transporte que quiera tener sus datos de sostenibilidad en orden debe, por tanto, no solo revisar sus propios sistemas, sino también contar con acuerdos sobre qué deben entregar los subcontratistas y en qué formato.
El consumo de combustible suele ser el punto de partida y, al mismo tiempo, el componente más fragmentado. Los datos de las tarjetas de combustible, los ordenadores de bordo, los sistemas de telemática y los recibos de combustible manuales suelen coexistir, con distintas resoluciones y distintas definiciones de lo que constituye un "trayecto". Un ordenador de bordo registra por vehículo, un proveedor de tarjetas de combustible factura por tarjeta, y ambos no coinciden automáticamente.
El software de planificación y TMS (sistemas de gestión del transporte) contiene datos sobre el grado de carga, los trayectos de retorno y los kilómetros en vacío, necesarios para poder imputar las emisiones por envío o por cliente. Estos sistemas están diseñados principalmente para la planificación operativa, no para la elaboración de informes de sostenibilidad, por lo que los campos necesarios a veces sí están presentes, pero no en el formato que exige un informe CSRD.
Los sistemas de RR. HH. y de personal contienen datos sobre los desplazamientos entre el domicilio y el trabajo y, en empresas con talleres propios, sobre el consumo energético de los inmuebles. Los departamentos de instalaciones a menudo gestionan por separado los contratos de energía de oficinas, puntos de carga y demás propiedades. Y luego está la carpeta de contratos y acuerdos con subcontratistas, en la que a veces sí y a veces no figura algo sobre el tipo de combustible o el tipo de vehículo utilizado.
En muchas empresas de transporte no hay una persona que supervise todas las fuentes mencionadas. El departamento de planificación conoce los trayectos, el gestor del parque de vehículos conoce el consumo de combustible, compras conoce a los subcontratistas, y finanzas debe, al final, convertir todo esto en una cifra para el informe. Sin una titularidad clara por cada dato, existe el riesgo de que nadie se sienta responsable de la exactitud de una cifra, y que solo al elaborar el informe se descubra que falta una fuente o que no concuerda.
Este es un patrón reconocible: también en los servicios profesionales y en el comercio minorista los datos están repartidos entre departamentos que cada uno posee solo una parte del panorama, sin que nadie vigile el conjunto. En el transporte se añade la complicación de que una parte sustancial de las fuentes se encuentra físicamente fuera de la empresa, en vehículos y en manos de socios.
Resulta tentador querer resolver esta fragmentación con software que combine automáticamente la telemática, los datos de las tarjetas de combustible y los datos del TMS. Ese tipo de software puede ser útil, pero solo si de antemano está claro qué dato debe proceder de qué fuente, quién controla ese dato y qué regla de calidad determina si un valor es creíble. Una herramienta que se coloca sobre un proceso desorganizado produce un informe más ordenado sobre las mismas cifras poco confiables. El orden correcto es, por tanto, primero el registro de datos y su procedencia, y solo después, eventualmente, un sistema que automatice ese flujo.
El Data Readiness Scan determina, para una empresa de transporte, qué dato procede de qué sistema: el consumo de combustible por vehículo o por trayecto, el grado de carga del TMS, el consumo energético de las sedes, y los datos que los subcontratistas entregan o precisamente no entregan. Para cada dato se registra quién es el propietario y qué regla determina si el valor es plausible, de modo que ante una auditoría quede claro de dónde procede una cifra y a quién se le puede preguntar. Este trabajo no trata del informe en sí ni de responder cuestionarios de clientes o bancos, sino de la capa de datos que los precede.
El scan está en construcción. Quien tenga interés puede inscribirse en la lista de espera; de momento no se vende nada que aún no esté terminado.
Una vez que está claro qué datos existen, quién los gestiona y de qué sistema proceden, surge de forma natural una pregunta siguiente: qué parte de la recopilación y el control de esos datos es trabajo manual que sigue recayendo en un planificador o controller, y qué parte es lo bastante repetitiva como para automatizarla. Esa misma cuestión se plantea en sectores como la educación y el sector agrícola, donde los datos operativos están tan dispersos como en el transporte. El escaneo de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede asumir la IA, y encaja precisamente en el momento en que el registro de datos del Data Readiness Scan está listo: primero saber dónde están los datos y quién es responsable de ellos, y solo después ver qué parte de su mantenimiento puede automatizarse.
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.