Um desvio de sinal é uma regra que diz: se este valor sair deste intervalo, então há algo que alguém deve analisar. Isso parece simples, mas a questão divide-se em três partes que devem ser respondidas separadamente. O que é um valor válido. O que é um desvio desse valor. E quem tem visibilidade sobre isso. Sem estes três elementos, um sinal não é mais do que um número que está registado em algum lugar.
Não é possível definir um desvio sem primeiro saber o que é normal. Para um consumo de energia por unidade, isso é um intervalo que depende da área, dos horários de funcionamento e da estação do ano. Para um número de colaboradores, é um intervalo que depende da dimensão da unidade. Essa amplitude tem de estar definida por ponto de dados antes de um sinal ter significado. Como determinar e registar essa amplitude está descrito em o que é um valor válido e quem nota quando algo corre mal. Sem esse passo, está a configurar um sinal sobre um valor que nunca foi ele próprio validado, e nesse caso não está de facto a sinalizar nada.
Um sinal pode reagir a coisas diferentes. Há o limite absoluto: um valor que se situa fora de um intervalo fisicamente ou logicamente possível, como um número negativo de colaboradores. Há o limite relativo: um valor que se situa dentro do possível mas que se desvia fortemente de períodos anteriores, como uma duplicação do consumo de água sem motivo claro. E há o desvio comparativo: um valor que se desvia de uma unidade comparável, como uma unidade que reporta o triplo dos resíduos de uma unidade de dimensão semelhante. Cada um destes três tipos exige uma regra diferente e um tipo diferente de dados de origem com que comparar. Um intermediário que apenas olha para o valor mais recente vê frequentemente apenas o primeiro tipo. O segundo e o terceiro exigem que tenha dados históricos ou comparáveis disponíveis, o que é uma razão para já ter isso em conta na configuração do registo de pontos de dados.
Um desvio que não chega a lado nenhum não é um sinal, é apenas uma linha de registo. Para cada sinal deve estar definido quem é o primeiro destinatário: normalmente é quem fornece o ponto de dados, não quem elabora o relatório. O departamento que fornece os dados pode verificar uma causa no momento em que o lembrete ainda está fresco. No momento do prazo de reporte, esse contexto já desapareceu muitas vezes. Além disso, deve estar definido o que acontece se o primeiro destinatário não reagir: o sinal passa, após um determinado período, para uma segunda pessoa, ou fica pendente. Esta questão está diretamente ligada à responsabilidade que já definiu previamente por ponto de dados, e aos controlos aplicáveis a esse ponto de dados — consulte que controlos correspondem a um ponto de dados e quem nota quando para saber como a sinalização e o controlo se articulam.
Um desvio pode ser um erro, mas também pode ser uma alteração real: uma fusão, uma nova unidade, uma mudança no ano de reporte. Uma regra de sinalização que não permite essa distinção conduz a dois problemas. Utilizadores que recebem demasiados sinais falsos acabam, a certo ponto, por ignorar todos os sinais. Utilizadores que recebem demasiado poucos sinais deixam precisamente de detetar o desvio que é relevante. Ambos são uma forma de falsa precisão: parece que o sistema está a vigiar, quando na prática já não filtra nada. Como evitar isso ao configurar limiares está descrito em como evitar a falsa precisão. Parte da solução consiste em tornar obrigatória a indicação de um motivo ao descartar um sinal: não para verificar quem cometeu um erro, mas para verificar se o próprio limiar deve ser ajustado.
Uma regra de sinalização idêntica para toda a organização ignora o facto de que as unidades por vezes trabalham com definições diferentes daquilo que medem, mesmo que o ponto de dados se chame o mesmo em todo o lado. Uma unidade que delimita as emissões de âmbito 3 de forma mais abrangente do que outra irá mostrar valores diferentes sem que haja algo de errado. Uma regra de sinalização que não tem isso em conta produz desvios falsos em cada comparação entre unidades. Em o que fazer com definições que diferem por unidade explica-se como registar essa diferença para que a regra de sinalização a possa ter em conta em vez de a confundir com um erro.
Configurar um desvio de sinal não exige software; exige que saiba, por ponto de dados, o que é válido, o que é um desvio, e quem o vê. É exatamente esse tipo de trabalho que o Data Readiness Scan mapeia: o registo de pontos de dados, as regras de qualidade correspondentes e a responsabilidade, para que um sinal se possa apoiar em algo em vez de numa fórmula isolada numa folha de cálculo. O scan em si está em desenvolvimento; quem já quiser começar com isto pode inscrever-se na lista de espera.
Uma vez essa estrutura estabelecida, surge uma questão subsequente: quem deve analisar diariamente esses sinais, e que parte desse trabalho de controlo é suficientemente repetitiva para ser entregue a uma máquina. Essa questão não pertence a esta página, mas ao scan de trabalho da FTE TO AI, que calcula, por tarefa, que parte do trabalho pode ser assumida por IA. Para analisar desvios rotineiros, questionar uma causa junto de um grupo fixo de fornecedores de dados e manter um registo de sinais, essa é frequentemente uma questão relevante.
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.