Você sabe que o relatório funcionou no mês passado: ninguém alterou os cálculos, o fluxo de trabalho continua sendo executado sem erros e, ainda assim, o número no dashboard simplesmente parece errado.
Então você começa a rastrear de trás para frente e, no fim, descobre o que mudou. Um novo valor de categoria chegou e nunca foi mapeado, uma fonte chegou com atraso ou uma junção que funcionou perfeitamente durante meses de repente está gerando linhas extras.
Se você já trabalha há algum tempo com analytics recorrentes, sabe como funciona. Encontrar o problema pode exigir investigação, mas o mais frustrante é saber que você já solucionou alguma versão do problema antes — e que a checagem que o teria identificado ainda está só na sua cabeça.
Você precisa incorporar mais desse conhecimento ao processo para que os problemas apareçam mais cedo, em vez de fazer você voltar às pressas pelo fluxo de trabalho pouco antes de o relatório ser enviado.
Comece com o que precisa ser verdade para esse relatório
Na geração de relatórios, a qualidade dos dados começa com o que você pede que os dados façam. O mesmo conjunto de dados pode funcionar perfeitamente bem para uma análise e ser inadequado para outra, portanto, uma checklist universal de "bons dados" só leva você até certo ponto.
Como a Gartner observa, "as ferramentas de qualidade de dados não existem sozinhas". O que importa é se elas viabilizam o trabalho de analytics e geração de relatórios que você precisa realizar.
Considere um relatório financeiro mensal, em que suas checagens podem ser bastante concretas:
- Todos os arquivos de origem esperados chegaram?
- A extração inclui o período completo de geração de relatórios?
- Os totais reconciliam com o valor de controle que você espera?
- Algum novo centro de custo apareceu sem mapeamento?
- Os dados ainda estão na granularidade esperada — por exemplo, uma linha por fatura?
Mude para um fluxo de trabalho diferente, e as checagens mudam com ele. Em um fluxo de trabalho de segmentação de clientes, entidades duplicadas ou a qualidade de correspondência podem ser muito mais importantes. Em um dashboard operacional, a maior preocupação pode ser se os dados de hoje apareceram quando você esperava.
É por isso que "dados limpos" não são uma linha de chegada muito útil. Uma data pode estar formatada corretamente e ainda pertencer ao mês errado, enquanto duas tabelas de origem podem parecer corretas até que a junção entre elas comece a criar duplicatas.
Você provavelmente já tem um processo de qualidade de dados
Se você já executa o mesmo relatório há algum tempo, provavelmente acumulou uma coleção de checagens sem nunca ter parado para chamá-las de "processo de qualidade de dados". Algumas estão no fluxo de trabalho, outras acontecem no Excel, e algumas são coisas de que você se lembra porque uma fonte surpreendeu você há três ciclos de geração de relatórios.
Enquanto isso, outra pessoa da sua equipe pode estar de olho em um problema completamente diferente porque já lidou com isso antes. Em pouco tempo, o processo fica dividido entre o que está integrado ao fluxo de trabalho e o que as pessoas sabem que precisam checar por fora. À medida que os dados mudam e novos problemas surgem, mais checagens são adicionadas.
Você não precisa de um software para tomar todas as decisões por você. O que ajuda é incluir mais checagens que você repete no processo, para que elas continuem lá quando novos dados chegarem.
A criação de perfis ajuda você a evitar criar regras no vácuo
Digamos que você esteja tentando decidir quando valores ausentes são suficientes para sinalizar um campo. Um limite faz mais sentido se você souber como o campo normalmente se comporta: uma queda de 99,9% de preenchimento para 94% conta uma história bem diferente de um campo que sempre ficou em torno de 90%.
Você pode se deparar com a mesma situação em relação à exclusividade. Antes de exigir que o ID da fatura seja exclusivo, certifique-se de que o fluxo de trabalho ainda tenha uma linha por fatura nesse estágio; caso contrário, você pode acabar com uma checagem que é acionada com tanta frequência que as pessoas deixam de prestar atenção nela.
Ao comparar plataformas, veja com que rapidez o perfil de dados mostra a você o contexto por trás de uma regra. Daqui a seis meses, você ou outro analista ainda deve ser capaz de dizer por que um limite existe, em vez de herdar um número que ninguém se lembra de ter escolhido.
As checagens que valem a pena manter geralmente são as que você já faz
Você provavelmente tem uma lista mental que repassa antes de divulgar um relatório. Talvez você sempre confira se o mês atual está lá, ou saiba que há uma junção que merece uma segunda olhada porque já adicionou linhas antes.
Essas são as checagens que vale a pena transformar em validação de dados repetível, principalmente quando há um motivo de negócios por trás delas. "Este campo não pode ser nulo" é útil, mas "toda loja ativa precisa de uma região antes que o relatório de vendas seja divulgado" explica à próxima pessoa por que a checagem existe e do que ela protege.
Uma checagem de qualidade dos dados com falha é só o começo
Digamos que seja fim de tarde e sua checagem de completude fique vermelha. Ótimo, você identificou algo — mas agora precisa entender o que aconteceu. Talvez alguns registros estejam ausentes; talvez seja uma grande parte dos dados. De qualquer forma, você precisa saber se o problema começou na fonte ou em algum ponto do fluxo de trabalho.
Se tudo o que a plataforma oferece é "falha na qualidade", você ainda fica preso fazendo o trabalho de detetive. Ao comparar plataformas, preste atenção na rapidez com que uma checagem que falhou leva você aos registros por trás dela. Quando o relatório precisa ser entregue em uma hora, esse caminho importa muito mais do que uma tela de status refinada.
Talvez 30 transações tenham passado sem mapeamento válido. Se o seu próximo passo for exportar esses registros, corrigi-los em outro lugar e trazê-los de volta para o fluxo de trabalho de geração de relatórios, você encontrou o problema sem tornar sua resolução muito mais fácil.
Às vezes, essa transferência faz sentido porque outra equipe é responsável pela decisão. Mas quando a lógica de negócios fica com a sua equipe, veja quanto da investigação e do acompanhamento você pode fazer sem sair do fluxo de trabalho.
O que você faz a seguir depende do que falhou
"Encontrar os dados incorretos" parece simples até você se deparar com uma exceção real. Talvez um novo código de produto apareça sem correspondência na sua tabela de mapeamento. Você pode ver quais registros foram afetados, mas a plataforma não tem como saber se esse produto pertence a Consumidor, Corporativo ou a uma categoria criada pela empresa ontem.
Outros problemas são mais fáceis porque a decisão já foi tomada. Se uma fonte enviar "N.Y." e "New York" de forma intercambiável e todos tiverem concordado com o padrão, a limpeza de dados pode aplicar a mesma correção sem que você precise rever isso todo mês.
É por isso que “corrige dados ruins automaticamente” não é um teste muito útil quando você está comparando plataformas. Alguns problemas têm uma resposta definida; outros ainda exigem seu julgamento. E, se uma fonte crítica estiver ausente, a medida certa pode ser interromper o relatório antes que ele avance ainda mais.
Você ainda está decidindo o que cada tipo de falha significa. O que você quer da plataforma é uma forma de tornar as decisões que você já definiu mais fáceis de repetir.
Compare plataformas com um fluxo de trabalho que você já conhece
Grades de recursos podem fazer com que plataformas de qualidade de dados muito diferentes pareçam estranhamente semelhantes. Criação de perfis, regras, monitoramento, automação — a maioria dos fornecedores pode apontar para algo em cada coluna, mas a lista não mostra como são as tardes de sexta-feira quando os números não se reconciliam.
Em vez disso, traga um fluxo de trabalho real para a avaliação, de preferência um que sua equipe conheça bem e que tenha um histórico por trás. Um relatório que ainda precisa de reconciliação manual ou tem um passo que todos sabem que precisa ser revisado dirá muito mais a você do que dados perfeitos de demonstração. Você poderá ver como a plataforma lida com o tipo de trabalho que sua equipe enfrenta em uma semana normal, e não apenas com o exemplo que ela foi criada para exibir.
Teste as regras em que seu relatório realmente se baseia
As checagens em que você confia normalmente vão além da validação básica em nível de campo. Talvez você precise garantir que todas as lojas que realizaram transações neste mês tenham uma região. Ou talvez o problema que você aprendeu a monitorar seja uma junção que às vezes cria linhas extras. Suas regras devem refletir os fatores que podem desestabilizar o relatório, não apenas se os campos passam por uma checagem técnica básica.
Use as regras das quais sua equipe depende na prática. Se forem difíceis de criar ou de entender para outro analista, preste atenção. Checagens importantes tendem a voltar para as planilhas ou para a rotina de pré-publicação de alguém quando a plataforma só lida bem com as mais simples.
Checagens claras e reutilizáveis também facilitam as transferências de tarefas. O analista que cobre o fluxo de trabalho pode ver o que observar sem precisar de um download de meia hora de tudo o que o relatório "às vezes faz".
Quebre algo e veja como a plataforma se comporta
Uma demonstração mostra muito mais quando os dados ficam um pouco confusos. Deixe de fora uma entrada que você sabe que o fluxo de trabalho precisa ou adicione um valor que não corresponda à lógica existente. Se as junções já causaram problemas antes, use um caso de teste que crie o mesmo tipo de linhas duplicadas.
Em seguida, acompanhe o problema e veja com que rapidez você pode ir da checagem com falha aos registros por trás dela. Você também quer saber se o fluxo de trabalho pode responder de forma diferente dependendo do que deu errado — parando devido a uma fonte ausente, por exemplo, enquanto envia uma correspondência incerta para revisão.
Dados de demonstração preparados podem fazer quase qualquer coisa parecer suave. Um caso de teste que se comporta mal dá a você uma noção muito melhor de como será usar a plataforma quando os dados reais fizerem a mesma coisa.
Onde os problemas na qualidade de dados tendem a aparecer na geração de relatórios
No momento em que você chega à geração de relatórios de dados, alguém está prestes a usar o resultado, que é quando um problema de qualidade fica muito mais difícil de ignorar.
Um dashboard pode ser atualizado com perfeição mesmo que o período de geração de relatórios mais recente esteja ausente, porque a visualização está fazendo exatamente o que foi instruída a fazer; o fluxo de trabalho simplesmente nunca checou se os dados esperados apareceram.
Uma junção pode pegar você da mesma forma. Ambas as entradas podem parecer corretas por si sós, mas se a relação entre elas mudar, você pode acabar repentinamente com linhas extras nas etapas seguintes. Se você espera uma linha por fatura, checar isso logo após a junção diz muito mais do que simplesmente confirmar que ambas as tabelas de origem pareciam corretas.
Às vezes, os próprios dados são perfeitamente válidos, mas a sua lógica de geração de relatórios nunca os viu antes. Talvez um novo canal de vendas apareça sem espaço nas categorias atuais de geração de relatórios. O valor não está errado; só precisa de uma decisão antes que o relatório fique pronto.
Quando uma plataforma dedicada de qualidade de dados ou observabilidade faz mais sentido
Às vezes, você está solucionando um problema maior do que saber se um fluxo de trabalho de geração de relatórios está pronto para ser usado. Se sua equipe precisa monitorar a qualidade em todo um grande ambiente de dados ou oferecer suporte ao monitoramento mais próximo da engenharia de dados, uma plataforma dedicada de qualidade de dados ou de observabilidade de dados pode ser a melhor opção.
Mas, se a maior parte dos seus problemas começa depois que uma checagem falha, observe atentamente o que acontece em seguida. Você quer saber se consegue acessar os registros afetados, lidar com o problema e manter o fluxo de trabalho em andamento sem enviar os dados por outro processo.
Essas são necessidades diferentes. Se sua prioridade é um monitoramento amplo em toda a empresa, avalie essa opção. Se sua equipe passa mais tempo investigando checagens que falharam em fluxos de trabalho de geração de relatórios, preste mais atenção à facilidade com que você pode lidar com o problema sem desmontar o fluxo de trabalho.
Veja como um fluxo de trabalho de analytics conectado funciona na prática
Considere um relatório semanal de inventário em que um fornecedor começa a enviar um valor de status que o fluxo de trabalho nunca viu antes. O relatório ainda pode ser executado, mas esses registros agora precisam de uma decisão antes que a saída esteja pronta.
Se você estiver testando uma plataforma em um caso como esse, acompanhe o valor inesperado ao longo do fluxo de trabalho. Você deve conseguir acessar os registros afetados sem transformar a investigação em um processo paralelo separado. E se o tratamento correto já for conhecido, essa lógica pode permanecer no fluxo de trabalho para que você não precise fazer a mesma correção novamente na próxima semana.
Se a resposta ainda não for conhecida, o fluxo de trabalho não deve fingir o contrário. Esses registros podem precisar de revisão antes que o relatório avance.
O que importa aqui é a distância entre identificar o problema e conseguir fazer algo útil a respeito. Um fluxo de trabalho conectado deve tornar esse caminho mais fácil de seguir sem exigir que você recomponha o processo ao longo do caminho.
Se você quiser ver como o Alteryx One lida com esse tipo de fluxo de trabalho de geração de relatórios, explore o Alteryx One.
Comece com um relatório que sua equipe conhece bem
Você provavelmente não precisa começar com o maior fluxo de trabalho da empresa. Escolha um relatório recorrente que sua equipe conheça bem o suficiente para apontar as partes que costumam causar problemas e, depois, pense nas checagens que existem ali porque algo deu errado antes.
Quais checagens ainda dependem de alguém se lembrar delas? Quais correções continuam aparecendo novamente? Se algo sério quebrasse amanhã, o fluxo de trabalho saberia o suficiente para parar ou continuaria até que alguém percebesse?
Essas perguntas são um teste muito melhor para avaliar uma plataforma de qualidade de dados do que um checklist genérico de recursos. Você está procurando uma maneira de tornar mais fáceis de repetir as checagens em que sua equipe já confia — sem tentar automatizar as decisões que ainda precisam de uma pessoa.
Se você quiser colocar essa abordagem à prova, inicie uma avaliação gratuita do Alteryx One com um relatório recorrente que sua equipe já conhece a fundo.