Que controlo corresponde a este ponto de dados, e quem se apercebe quando o valor se desvia

Um ponto de dados sem controlo é um número que ninguém contesta. Consta no relatório, provém de um sistema ou de uma folha de cálculo, e é aceite porque não há motivo para o questionar. Só quando uma parte externa faz uma pergunta, ou quando um número muda repentinamente por um fator de dez em relação ao ano anterior, é que se nota que nunca ninguém olhou para ele. Nessa altura já é tarde para reconstruir onde correu mal.

A pergunta que evita isto é simples de formular e difícil de responder sem estrutura: que controlo corresponde a este ponto de dados, e quem se apercebe quando algo corre mal. São duas perguntas, e ambas devem ter resposta antes de um número entrar num relatório.

O que é um valor válido, e o que não é

Cada ponto de dados tem limites. Um consumo de energia não pode ser negativo. Um número de fte não é um decimal. Uma percentagem não passa de cem. Isto parece evidente, mas na prática este tipo de limites não está registado em lugar nenhum — está na cabeça de quem processa os dados há anos, e desaparece quando essa pessoa muda de função.

Registar um valor válido não significa apenas anotar um limite inferior e um limite superior. Significa também registar em que unidade um ponto de dados é fornecido, que formatos de data são permitidos, e se um campo vazio é um resultado válido ou um sinal de que falta algo. Sem esse acordo, cada excepção é avaliada de novo, por quem por acaso está a olhar para ela nesse momento. O que exatamente conta como válido, e quando um valor-limite é mais uma suposição do que uma regra, está desenvolvido em a página sobre o que é um valor válido.

A diferença entre um erro e um sinal

Nem todo o desvio é um erro. Um ponto de dados pode estar totalmente dentro dos limites válidos e ainda assim ser um sinal — um consumo que desce repentinamente, um número que é três vezes superior ao do trimestre anterior, um fornecedor que, pela primeira vez em dois anos, não entrega dados. Não são valores inválidos. São valores que pedem o olhar de alguém que conhece o contexto.

Uma regra de sinal é, portanto, algo diferente de uma regra de validação. A validação determina se um valor pode existir. Um sinal determina se um valor, ainda que válido, é mesmo assim motivo para se olhar. A forma como esse limiar é definido — percentagem fixa de desvio, comparação com uma série histórica, ou uma combinação — depende do ponto de dados e da estabilidade normal da atividade subjacente. A conceção dessa regra, incluindo o equilíbrio entre demasiados e demasiado poucos sinais, está descrita em a página sobre como definir um desvio de sinal.

Quem se apercebe não é uma questão técnica

Uma regra que ninguém vê não é uma regra. Quando uma verificação de validação ou de sinal dispara em algum lugar de um sistema, tem de estar definido quem recebe a notificação e o que essa pessoa faz com ela. É quem introduz os dados, o responsável pelo ponto de dados, ou alguém que tem uma visão de conjunto antes de o relatório ser compilado? Sem um destinatário designado, um sinal desaparece num registo que ninguém consulta.

Isto está relacionado com a responsabilidade, e a responsabilidade está relacionada com um problema que em muitas organizações permanece sem resolução: diferentes unidades utilizam definições distintas para o que, no papel, é o mesmo ponto de dados. Uma unidade conta os ftes incluindo trabalhadores temporários, outra não. Quando dispara um sinal de que um valor se desvia, a primeira pergunta muitas vezes não é se o valor está correto, mas se todos partilham a mesma definição. A forma de lidar com isto está descrita em a página sobre definições diferentes entre unidades.

Porque isto não começa com uma ferramenta

É tentador procurar estes controlos num pacote de software: algo que alerta, valida e reporta automaticamente. Mas uma ferramenta que executa controlos sobre dados cujo valor válido ninguém registou não está a executar um controlo — está apenas a produzir um resultado com boa aparência sobre um processo que ainda não foi pensado a fundo. As regras têm de existir primeiro, independentemente do sistema que as venha a aplicar. Esta ordem, e porque inverte-la geralmente leva a decepção, está explicada em a página sobre comprar primeiro uma ferramenta ou organizar primeiro o processo.

O que isto proporciona antes de se construir algo

Quando, para cada ponto de dados, está definido o que é um valor válido, quando dispara um sinal, e quem recebe esse sinal, surge um registo que não só documenta como também é utilizável como caderno de requisitos. Esse registo é exatamente o que é necessário para determinar o que um sistema — construído internamente ou adquirido — deverá futuramente ser capaz de fazer. Sem esse caderno de requisitos, cada aquisição torna-se uma aposta. A forma de traduzir isto em requisitos funcionais que resultam do seu próprio processo, em vez de resultarem de um fornecedor, está descrita em a página sobre requisitos funcionais a partir do seu próprio processo.