A partir do momento em que os dados de sustentabilidade provêm de mais do que uma unidade de negócio, o problema surge antes mesmo de o registo existir. Cada unidade tem os seus próprios sistemas, as suas próprias folhas de cálculo, as suas próprias definições do que significa um ponto de dados. Um registo que não organize isso irá, mais tarde, contar o mesmo fluxo três vezes ou não o contabilizar de todo.
Um registo de pontos de dados não é uma lista de temas de relato, mas sim um registo ao nível do ponto de dados individual: as emissões de escopo 2 do estabelecimento A, o número de FTE com contrato temporário na unidade B, o consumo de água do local C. Por cada ponto de dados deve estar registado exatamente o que mede, em que unidade, sobre que período e para que entidade. Sem esses quatro elementos, um ponto de dados não é rastreável e, portanto, não é verificável.
Além disso, o registo contém, por ponto de dados, a fonte: o sistema, o ficheiro ou a pessoa de onde provém o valor. Isto nem sempre é tão simples como parece. Com várias unidades de negócio, acontece regularmente que um ponto de dados é preenchido sem que ninguém consiga indicar de onde provém; o que fazer com um ponto de dados sem fonte identificável é, por isso, uma questão que o próprio registo deve conseguir responder, e não algo a apurar posteriormente.
A tentação, com várias unidades de negócio, é deixar cada unidade fornecer a sua própria lista separadamente e depois juntar essas listas. Isso não funciona, porque as unidades raramente utilizam as mesmas definições. Uma unidade relata o consumo de energia por estabelecimento, outra por linha de produção. Uma inclui trabalhadores temporários no efetivo, outra não. Quando essas listas são combinadas sem primeiro alinhar as definições, surgem duplicações que não são reconhecíveis como tal.
A ordem que funciona é: primeiro determinar quais os pontos de dados que realmente importam para a organização como um todo, independentemente de qual unidade os fornece. Trata-se de uma questão de necessidade, não de disponibilidade — quais os pontos de dados de que realmente necessita é uma pergunta diferente de quais os pontos de dados que já existem em algum lugar numa folha de cálculo. Só depois se determina, por ponto de dados, qual a unidade, qual o sistema e qual a pessoa que constitui a fonte. Assim, surge um único registo com uma única definição por ponto de dados, no qual várias unidades fornecem dados sem que o ponto de dados em si se duplique.
Detetar duplicações continua a ser necessário depois disso, pois mesmo com boas definições, duas unidades podem registar inconscientemente o mesmo facto subjacente sob um nome diferente. Como o notar — como reconhecer um ponto de dados duplicado entre unidades de negócio — é uma verificação que se realiza sobre o próprio registo, não sobre o relatório que dele resulta posteriormente.
Um erro frequente é atribuir a titularidade ao nível da unidade: a unidade A é responsável por todos os dados da unidade A. Isso funciona enquanto as unidades permanecem claramente delimitadas, mas com várias unidades de negócio com processos que se sobrepõem — um departamento de compras partilhado, um parque automóvel central — essa atribuição rapidamente se torna pouco clara. É melhor atribuir a titularidade por ponto de dados: um único nome capaz de explicar de onde vem o valor, qual é a unidade e quando foi atualizado pela última vez. Esse nome não precisa de ser o de quem insere o valor, mas sim o de quem conhece a fonte.
Quantos dos pontos de dados existentes já têm essa fonte identificável é geralmente a primeira pergunta que surge quando isto é verificado de forma sistemática. Quantos dos seus pontos de dados têm uma fonte é exatamente a pergunta que deve ser respondida separadamente por cada unidade de negócio, porque a resposta pode variar bastante entre unidades.
Com várias unidades de negócio, a tentação é esperar até que todas as unidades tenham o mesmo nível de profundidade antes de considerar o registo concluído. Esse não é um critério realista. Um registo está concluído quando, para cada ponto de dados, é claro quem é o titular, qual é a fonte e qual a regra de qualidade que se lhe aplica — mesmo que essa resposta seja, para alguns pontos de dados, por agora, "fonte desconhecida, ação a cargo da unidade X". A incompletude que é visível e atribuída é gerível; a incompletude que permanece escondida por detrás de um valor preenchido, não o é. O que este critério implica exatamente está detalhado em quando um registo está concluído com várias unidades de negócio.
O tempo necessário para elaborar um registo deste tipo depende do número de unidades de negócio, do número de sistemas por unidade e do grau em que as definições já estão alinhadas entre si. Numa organização com poucas unidades e fontes claras, isso representa consideravelmente menos trabalho do que numa organização com dezenas de unidades em diferentes sistemas ERP. Uma indicação de onde vem esse trabalho encontra-se em quanto tempo demora a pôr um tema em ordem.
A elaboração e manutenção de um registo de pontos de dados abrangendo várias unidades de negócio consiste numa série de tarefas reconhecíveis: apurar definições, identificar fontes, atribuir titulares, detetar duplicações. Parte desse trabalho é suficientemente repetível para ser automatizado; outra parte exige uma avaliação que deve permanecer a cargo de uma pessoa. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte desse trabalho pode ser assumida pela IA, para que fique claro onde continuam a ser necessárias horas humanas e onde não é esse o caso.
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.