O setor de transportes tem uma característica que poucos outros setores partilham: a maior parte das emissões de CO2 surge fora do escritório, espalhada por veículos, viagens e subcontratados que não estão todos no mesmo sistema. Enquanto um edifício de escritórios é relativamente simples de medir, a frota de uma empresa de transportes é composta por dezenas ou centenas de fontes móveis individuais, cada uma com o seu próprio consumo de combustível, grau de carregamento e rota. As emissões não estão num edifício, mas sim numa soma de viagens, e essa soma tem de vir de vários sistemas ao mesmo tempo.
A isto acrescenta-se uma segunda camada: uma parte significativa dos quilómetros percorridos é muitas vezes feita não pela frota própria, mas por subcontratados, transportadores fretados ou parceiros da cadeia. Essas emissões enquadram-se, na maioria dos casos, no âmbito 3 (scope 3), e os dados a este respeito raramente estão disponíveis de forma padronizada. Uma empresa de transportes que queira ter os seus dados de sustentabilidade em ordem tem, portanto, de examinar não só os seus próprios sistemas, mas também ter acordos sobre o que os subcontratados fornecem e em que formato.
O consumo de combustível é geralmente o ponto de partida e, ao mesmo tempo, o elemento mais fragmentado. Dados de cartões de combustível, computadores de bordo, sistemas de telemática e talões de abastecimento manuais existem frequentemente em paralelo, com resoluções diferentes e definições diferentes do que constitui uma 'viagem'. Um computador de bordo regista por veículo, um fornecedor de cartões de combustível fatura por cartão, e os dois não estão automaticamente sincronizados.
O software de planeamento e TMS (sistemas de gestão de transportes) contém dados sobre o grau de carregamento, viagens de retorno e quilómetros vazios, necessários para poder atribuir emissões por envio ou por cliente. Estes sistemas são construídos principalmente para o planeamento operacional, não para relatórios de sustentabilidade, pelo que os campos necessários por vezes existem, mas não no formato exigido por um relatório CSRD.
Os sistemas de RH e de pessoal contêm dados sobre deslocações casa-trabalho e, em empresas com oficinas próprias, sobre o consumo de energia dos edifícios. Os departamentos facilities gerem muitas vezes, separadamente, os contratos de energia de escritórios, postos de carregamento e outros imóveis. E depois há ainda a pasta com contratos e acordos de subcontratados, que por vezes contém informação sobre o tipo de combustível ou o tipo de veículo utilizado, e por vezes não.
Em muitas empresas de transportes não existe uma pessoa que tenha uma visão de todas as fontes acima mencionadas. O departamento de planeamento conhece as viagens, o gestor da frota conhece o consumo de combustível, as compras conhecem os subcontratados, e a área financeira tem, no fim, de transformar tudo isso num número de relatório. Sem um proprietário claro por cada ponto de dados, existe o risco de ninguém se sentir responsável pela exatidão de um número, e de só se descobrir, ao elaborar o relatório, que falta uma fonte ou que os dados não coincidem.
Este é um padrão reconhecível: também nos serviços empresariais e no comércio a retalho os dados estão dispersos por departamentos que têm cada um apenas uma parte da imagem, sem que ninguém vigie o todo. No transporte, acrescenta-se a complicação de que uma parte substancial das fontes se encontra fisicamente fora da empresa, em veículos e junto de parceiros.
É tentador querer resolver esta fragmentação com software que combine automaticamente telemática, dados de cartões de combustível e dados de TMS. Esse software pode ser útil, mas apenas se estiver claramente definido de antemão qual o ponto de dados que deve provir de qual fonte, quem controla esse ponto de dados e que regra de qualidade determina se um valor é credível. Uma ferramenta colocada sobre um processo desorganizado produz apenas um relatório mais arrumado sobre os mesmos números pouco fiáveis. A ordem correta é, portanto, primeiro o registo dos pontos de dados e da sua origem, e só depois, eventualmente, um sistema que automatize esse fluxo.
A Data Readiness Scan mapeia, para uma empresa de transportes, qual o ponto de dados que provém de qual sistema: consumo de combustível por veículo ou por viagem, grau de carregamento a partir do TMS, consumo de energia das instalações, e os dados que os subcontratados fornecem ou, precisamente, não fornecem. Para cada ponto de dados, regista-se quem é o proprietário e qual a regra que determina se o valor é plausível, de modo a que, numa auditoria, seja claro de onde vem um número e a quem se pode perguntar por ele. Este trabalho não é sobre o relatório em si, nem sobre responder a questionários de clientes ou bancos, mas sobre a camada de dados que precede tudo isso.
O scan está em construção. Quem tiver interesse pode inscrever-se na lista de espera; não se vende, por agora, nada que ainda não esteja concluído.
Assim que estiver claro quais os pontos de dados que existem, quem os gere e de que sistema provêm, surge naturalmente a questão seguinte: que parte da recolha e verificação desses pontos de dados é trabalho manual que continua a cargo de um planeador ou controller, e que parte é repetitiva o suficiente para automatizar. A mesma questão surge em setores como a educação e o setor agrícola, onde os dados operacionais estão tão dispersos como no transporte. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, ligando-se assim ao momento em que o registo de pontos de dados da Data Readiness Scan está concluído: primeiro saber onde estão os dados e quem é responsável por eles, só depois ver que parte da sua manutenção pode ser automatizada.
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.