Uma fábrica pesa o peso dos resíduos na báscula. Outra fábrica estima-o com base no volume do contentor. Ambas fornecem um valor para a mesma linha do relatório. Ninguém mentiu, ninguém cometeu um erro. Simplesmente nunca ficou registado qual é exatamente a definição desse ponto de dados, e por isso cada unidade escolheu a interpretação mais lógica que tinha à disposição.
Isto não é uma excepção. É o estado normal de uma organização em que a mesma métrica é fornecida por diferentes equipas, com diferentes sistemas de origem e diferentes históricos. A questão não é como eliminar esta diferença antes de ela surgir. A questão é o que faz com ela quando a detecta.
O passo que costuma ser ignorado é que a própria definição fique registada em algum lugar. Não na cabeça do controller que faz assim há anos, mas num registo: este ponto de dados significa isto, é medido desta forma, e estas unidades contam ou não. O que é um valor válido dentro disso e quem repara quando uma entrega cai fora disso está descrito na página sobre o que é um valor válido e quem repara quando um valor sai desse âmbito. Sem esse registo, cada soma feita entre unidades é uma soma de coisas que não são exactamente iguais, embrulhada num único número que parece inequívoco.
Este registo é exactamente o trabalho do Data Readiness Scan: não reescrever o relatório, mas construir o registo de pontos de dados no qual, para cada ponto de dados, consta o que é, de onde vem e quem assume a responsabilidade por ele. Esse registo é o local onde a diferença entre unidades se torna visível, em vez de só se tornar visível depois de o número já ter sido somado.
Depois de constatar que a unidade A e a unidade B entendem algo diferente pelo mesmo ponto de dados, existem grosso modo três rotas.
A primeira é harmonizar: impor uma única definição para toda a organização, com todas as adaptações de sistema que isso implica. Essa é muitas vezes a rota certa a longo prazo, mas não é algo que se resolva de um dia para o outro.
A segunda é documentar e corrigir: deixar o desvio onde está, mas registar a sua dimensão e, através de uma conversão fixa, garantir que o total fica correcto. Isto funciona quando a diferença é estável e conhecida — por exemplo, quando uma unidade utiliza estruturalmente um método de medição diferente que pode ser reconduzido ao original.
A terceira é sinalizar: não corrigir, mas assinalar sempre que uma entrega se desvia do padrão a que está habituado nessa unidade. Como configurar esse tipo de desvio de sinal e quem recebe a notificação está explicado na página sobre como configurar um desvio de sinal e quem repara quando isso acontece. Esta rota não existe para resolver o problema, mas para evitar que ele passe despercebido enquanto trabalha numa solução estrutural.
Qual rota é adequada depende de quantas unidades apresentam desvios, de quão estável é esse desvio, e de quanto tempo existe antes de o número entrar num período de relato. Essa é uma decisão que varia de organização para organização e que este registo não toma por si — mas torna visível que a decisão tem de ser tomada.
A diferença de definições é um dos erros mais silenciosos que existem, porque cada unidade tem razão isoladamente. A unidade que estima com base no volume do contentor não está a fazer nada de errado dentro do seu próprio processo. O problema só surge ao nível em que os números se juntam, e é precisamente aí que muitas vezes não há ninguém designado para verificar se as definições subjacentes são sequer comparáveis.
É por essa razão que a responsabilidade por cada ponto de dados é tão importante como a própria definição. Que controlos pertencem a um ponto de dados e quem repara quando um desses controlos é ignorado está descrito na página sobre que controlos pertencem a um ponto de dados e quem repara quando falta um. Sem um responsável designado, a pergunta 'mas quem vê realmente isto' fica sem resposta, mesmo que a definição esteja registada em papel.
É tentador querer resolver este problema com um sistema que normalize automaticamente as entregas. Mas uma ferramenta colocada sobre um conjunto de pontos de dados não definidos não normaliza nada — apenas embrulha as mesmas diferenças numa interface mais elegante. A ordem que se mantém válida é primeiro registar a definição e a responsabilidade, e só depois ver que sistema se adequa a isso. Porque essa ordem não é acidental está explicado na página sobre comprar primeiro uma ferramenta ou estruturar primeiro o processo.
Depois de, para cada ponto de dados, estar definido qual é a definição, quem é o responsável e que desvios são sinalizados, surge um outro tipo de pergunta: quem vai realizar o trabalho associado a esses controlos — o recálculo, o contacto com a unidade que apresenta desvio, a manutenção do próprio registo. Parte desse trabalho é suficientemente repetitivo para ser transferido para um passo automático, outra parte exige uma avaliação que continua a caber a uma pessoa. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte dessa tarefa pode ser assumida pela IA, com base no mesmo tipo de concretização deste registo: não a questão de saber se a automatização é possível, mas que parte de que tarefa é que se aplica.
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.