Um número errado em um relatório finalizado quase nunca vem do fluxo de trabalho que o gerou. Quando um dashboard mostra um número que parece incorreto, o reflexo é abrir o fluxo de trabalho e começar a verificar a lógica. Geralmente, a lógica foi executada exatamente como planejado; o defeito entrou antes, em dados que ninguém analisou primeiro.
Os problemas mais comuns se repetem entre as equipes. Um valor nulo deveria ter interrompido um cálculo, mas passou em branco. Uma linha duplicada inflou uma contagem. Uma leitura ficou fora de um intervalo válido sem acionar nenhum alerta. Uma alteração de esquema ocorreu silenciosamente e mudou até mesmo o significado de uma coluna.
Reconstruir o fluxo de trabalho depois que algo quebra não resolve nada. Colocar uma verificação no ponto em que os dados entram no processo resolve, e essa verificação precisa funcionar para três pessoas diferentes, não apenas para quem o construiu.
O analista herda todos os defeitos que o fluxo de trabalho não detecta
Para o analista responsável pelo fluxo de trabalho, a validação é um hábito manual que compete com um prazo, e hábitos manuais são a primeira coisa deixada de lado quando o prazo fica apertado. Não há uma maneira sistemática de confirmar se a entrada está correta antes que o fluxo de trabalho seja executado com base nela.
Dana é responsável exatamente por esse problema. Ela é analista na equipe de analytics da fábrica de um fabricante de autopeças tier 1, e seu fluxo de trabalho semanal de rendimento de primeira passagem extrai leituras do feed do MES da linha de montagem final para o relatório que a fábrica analisa toda segunda-feira de manhã. A equipe de operações se apoia nesse relatório para decidir se uma linha precisa de atenção antes do início do próximo turno, por isso um número errado não fica simplesmente esquecido em uma planilha.
Ela costumava conferir visualmente a contagem de linhas e verificar pontualmente uma amostra de leituras antes de gerar o relatório toda semana. Isso funcionava bem quando o volume era baixo, quando algumas poucas leituras podiam representar todo o turno. À medida que a linha passou a gerar centenas de leituras por dia, a verificação pontual se reduziu a uma rápida olhada antes de um prazo e, depois, a confiar totalmente no feed de dados.
Uma atualização de firmware no sensor de torque da estação de montagem final alterou o que acontecia quando uma leitura ficava abaixo de 2,4 Nm. Em vez de registrar essas leituras em log como falhas, o sensor simplesmente parou de gravar uma linha para elas. As unidades fora de especificação nunca apareceram no conjunto de dados.
O cálculo de rendimento da Dana só considerava leituras aprovadas. Ele indicava que o rendimento de primeira passagem estava subindo por três semanas consecutivas, enquanto a taxa real de rejeição da linha aumentava silenciosamente por trás disso.
A lacuna era mais profunda do que o sensor. Ninguém havia inserido a especificação real de torque, 2,4 a 2,6 Nm, na própria tabela de limites do MES. Ela existia apenas na planilha pessoal de um engenheiro de qualidade, portanto, mesmo um conjunto de dados completo não teria nada armazenado com o que se comparar.
Esse é, antes de tudo, um problema de perfilamento: validar o que realmente está nos dados de entrada antes de confiar no que sai do outro lado, em comparação com um limite de especificação que esteja em algum lugar além do arquivo de uma pessoa. Ele precisa ser executado como parte da execução normal do fluxo de trabalho, não como uma tarefa manual separada que compete com a mesma pressão de prazos que causou a lacuna em primeiro lugar.
O que uma checagem precisaria detectar
- Uma comparação de contagem de linhas em relação ao volume de produção esperado para o turno, para identificar leituras silenciosamente ausentes, e não apenas as incorretas.
- Uma validação de intervalo e limite em relação a um limite de especificação armazenado, e não naquele que só existe no arquivo de uma única pessoa.
- Uma verificação de valores nulos ou em branco no próprio campo do sensor, já que essa falha apareceu como ausência, não como um valor de erro.
- Uma retenção do lote, não apenas uma anotação, quando um turno falha nessas verificações, para que um turno ruim não entre no número semanal sem ser notado.
Antes que o próximo relatório seja divulgado, vale a pena rastrear o último número não explicado até sua real origem. Na maioria das vezes, o fluxo de trabalho cumpriu seu papel. Os dados que chegavam até ele eram o problema, e ninguém os conferiu na entrada.
A TI não vai confiar em um fluxo de trabalho que não pode validar/confirmar
A TI faz uma pergunta diferente da que o analista faz. O analista quer saber se os dados passaram na verificação. A TI quer saber quem alterou a verificação, quando a alterou e se essa alteração pode ser comprovada após o fato.
Essa dúvida surgiu no momento em que a equipe de Dana quis que a verificação de rendimento fosse executada automaticamente a cada turno, em vez de apenas quando ela se lembrava de checar. A primeira dúvida da TI foi focada no acesso, e não na lógica: quem mais poderia editar os limites de especificação por trás disso e se uma alteração nesses limites deixaria algum rastro visível.
As equipes que avaliam qualquer plataforma para esse tipo de trabalho buscam as mesmas duas coisas: alterações na lógica do fluxo de trabalho que sejam registradas em log e atribuíveis, e acesso controlado a quem pode editar uma verificação em execução na produção. Nenhum dos dois é opcional a partir do momento em que uma verificação deixa de ser um hábito pessoal e se torna algo de que uma fábrica depende a cada turno. Um fluxo de trabalho executado de forma não assistida ainda é um código que acessa dados de produção, e a equipe de TI o trata dessa maneira, independentemente de quem o escreveu.
A tensão é real e não se resolve por conta própria. Os analistas querem uma verificação que seja rápida de ajustar no momento em que um limite de especificação muda, já que um processo de alteração lento só incentiva as pessoas a contornar a verificação em vez de atualizá-la. A TI quer que cada um desses ajustes seja rastreável, exatamente pelo mesmo motivo: uma alteração não rastreada é indistinguível de um erro até que alguém prove o contrário.
Um fluxo de trabalho que torna as alterações fáceis, mas invisíveis, não satisfaz nenhuma das pessoas. Isso apenas transfere o risco de uma verificação que pode estar errada para uma verificação que pode ter sido alterada por qualquer pessoa, sem nenhum registro disso.
O que a TI precisa de uma solução é específico: as alterações precisam ser atribuíveis e revisáveis, sem transformar cada ajuste de limite de especificação em uma fila de tickets que desestimule os analistas a manterem a checagem atualizada, para começo de conversa. Erre esse equilíbrio para qualquer um dos lados e a checagem deixa de ser confiável para alguém.
O que a TI realmente avalia antes de confiar em um fluxo de trabalho
- Quem pode ver, editar ou executar o fluxo de trabalho que contém a verificação, e não apenas quem pode ver o relatório resultante.
- Se uma alteração na lógica da verificação, como um limite de especificação, é registrada com quem a fez e quando.
- Se uma verificação com falha fica visível em algum lugar onde um administrador possa vê-la, não apenas no próprio log de execução do analista.
- Por quanto tempo esse histórico de alterações é mantido e se pode ser exportado para uma análise de conformidade.
O diretor da fábrica não vê o cheque, apenas o valor que ele teria evitado
O diretor da fábrica nunca vê a checagem, apenas o número que ela teria identificado ou deixado passar. Apresentar um número de rendimento semanal para a diretoria significa confiar no fluxo de trabalho por trás dele às cegas, sem ter como saber se algo realmente validou o número antes de ele chegar à apresentação.
Foi exatamente isso que aconteceu na fábrica da Dana. Três semanas consecutivas de aumento nos números de rendimento de primeira passagem foram para a revisão da liderança antes que uma reclamação de cliente sobre unidades com defeito forçasse uma auditoria manual. A auditoria identificou a lacuna no sensor apenas depois do ocorrido; a essa altura, o número reportado aos níveis superiores já estava incorreto havia três ciclos de revisão.
O padrão não se limita a uma única fábrica. Uma pesquisa da Deloitte de 2025 com 600 executivos seniores do setor de manufatura revelou que a expansão de iniciativas de manufatura inteligente e IA é limitada, em todo o setor, por baixa qualidade dos dados, governança fraca e sistemas fragmentados.
Os riscos também aparecem no nível executivo. Um estudo de 2025 do IBM Institute for Business Value constatou que 43% dos diretores de operações identificam problemas de qualidade de dados como sua prioridade de dados mais significativa, à frente de quase tudo o que disputa sua atenção.
Um diretor de fábrica não se preocupa com a mecânica de uma verificação. A única pergunta que importa ao entrar em uma reunião de liderança é se o número diante deles já foi validado, e não se a equipe consegue explicar depois por que não foi.
Um número incorreto de rendimento reportado aos superiores durante três semanas não é um problema de dados do ponto de vista do diretor de uma fábrica. É uma falha de qualidade que afeta o cliente e um problema de credibilidade na próxima vez que a equipe reportar qualquer número. Reconstruir essa confiança leva muito mais tempo do que as três semanas que foram necessárias para perdê-la.
Onde os três interesses se alinham — e onde não se alinham
Os três stakeholders são atendidos pela mesma base: uma checagem que é executada automaticamente, todas as vezes, sem depender de um analista se lembrar de verificar antes do prazo. Isso é um ponto em comum.
Onde eles divergem é no que cada um precisa ver a respeito. Tornar uma verificação rápida para um analista ajustar, digamos quando um limite de especificação muda ou um sensor é substituído, pode ir diretamente contra a necessidade da TI de que essa mesma mudança seja revisada e atribuível. Velocidade e rastreabilidade puxam em direções opostas, a menos que ambas sejam projetadas simultaneamente.
O segundo ponto de atrito fica entre o analista e o diretor da fábrica. Um líder quer um número exato, ou uma sinalização clara de que algo falhou, e não o nível de detalhes de que um analista ou a equipe de TI precisa quando uma verificação realmente falha. Entregar um log de execução a um diretor não soluciona nada, assim como entregar a um analista apenas uma sinalização de aprovação ou reprovação também não soluciona nada; cada stakeholder precisa de um recorte diferente do mesmo evento.
Isso se transforma em um requisito, não em uma concessão negociada: a verificação em si precisa ser idêntica para todos, automatizada e executada no mesmo agendamento, independentemente de quem esteja acompanhando. O que muda é o que cada stakeholder vê sobre isso: um log de edição para a TI, uma sinalização de aprovação ou reprovação para o diretor, um número validado para o analista usar como base.
Problemas de qualidade dos dados não gerenciados acarretam um custo real e quantificado. As organizações perdem pelo menos $ 12,9 milhões por ano, em média, de acordo com pesquisas da Gartner. Esse valor se mantém em diversos setores justamente porque a falha subjacente é a mesma observada na fábrica da Dana: ninguém é responsável pela verificação em si, de modo que o custo de uma falha é descoberto nas etapas seguintes, por quem estiver com o número incorreto quando ele finalmente aparecer.
Se executasse o cenário novamente, a mesma verificação incorporada teria atendido aos três. Isso teria dado a Dana a validação da contagem de linhas e do limite que ela costumava fazer manualmente. Isso teria dado à equipe de TI uma alteração na lógica dos limites de especificação visível em algum lugar além da caixa de entrada dela. E isso teria dado ao diretor da fábrica um número de rendimento já validado, em vez de um que ficasse esperando que alguém percebesse um problema.
O que uma solução deve satisfazer para todos os três
O requisito para todos os três stakeholders é o mesmo. A verificação precisa estar dentro do próprio fluxo de trabalho, e não no hábito de uma pessoa se lembrar de olhar, e precisa ser executada em um agendamento que não dependa de ninguém solicitá-la.
Isso significa que o fluxo de trabalho precisa de uma forma de verificar, coluna por coluna, se os dados de entrada estão completos e válidos antes de serem usados, e de uma maneira de corrigir problemas comuns, como nulos, caracteres soltos e uso inconsistente de maiúsculas e minúsculas, como parte do mesmo processo que prepara os dados, e não em uma etapa manual separada. Essa segunda parte é o que a limpeza de dados realmente significa na prática: corrigir os dados, e não apenas sinalizá-los.
O requisito da TI mencionado anteriormente era específico: um registro de quem alterou a verificação e quando, que possa ser comprovado posteriormente. Plataformas como o Alteryx One atendem a essa necessidade por meio de logs de auditoria, que monitoram alterações na lógica do fluxo de trabalho como eventos registrados em log, atribuíveis e exportáveis, mantidos separados do próprio resultado de aprovação ou reprovação da verificação, em vez de substituí-lo.
Equipes que ainda estão desenvolvendo essa primeira camada podem começar com estes recursos de preparação de dados, que explicam o funcionamento com mais detalhes.
Essa verificação só se torna rotina quando deixa de depender de alguém para ser executada manualmente. O mesmo fluxo de trabalho pode ser agendado para ser executado automaticamente a cada turno, de modo que a sequência de perfilamento e limpeza se repita por conta própria, em vez de depender de alguém se lembrar de fazer a verificação.
Uma ferramenta de criação de perfil coluna por coluna pode mostrar valores nulos, em branco e fora do intervalo à medida que os dados passam pelo fluxo de trabalho, o que responde diretamente ao problema original do analista: ver o que realmente está lá antes de confiar nos dados em etapas posteriores.
Um passo de limpeza dedicado lida com as correções comuns, como nulos, espaços em branco indesejados e uso inconsistente de maiúsculas e minúsculas, como parte desse mesmo processo, em vez de ser uma tarefa separada encaixada às pressas antes de um prazo.
Montando a justificativa compartilhada
Apresentar isso como “uma nova ferramenta para qualidade de dados” convida ao escrutínio do orçamento e a objeções vagas. O argumento mais convincente se baseia na falha específica que o cenário revelou: três semanas de um número incorreto chegando à análise da liderança e a correção específica que isso exige: verificações incorporadas ao fluxo de trabalho e agendadas para execução, em vez de depender da memória.
O argumento do analista deve quantificar o próprio modo de falha, e não um agregado vago do setor. Uma verificação não realizada não custa a “qualidade dos dados” em termos abstratos. Custa o equivalente a um turno inteiro de unidades fabricadas fora da tolerância correta antes que alguém perceba, resultando em retrabalho ou refugo, além das horas gastas depois para reconstruir o que realmente aconteceu na linha.
O pedido da TI é menor do que parece. Em vez de pedir que alguém confie cegamente na planilha do analista, pede-se para ver a lógica da verificação e o histórico de alterações — uma solicitação mais restrita e mais fácil de responder do que uma análise completa da plataforma, e justamente a que a TI realmente precisa ter respondida antes de aprovar. Estruturada dessa forma, a conversa passa de uma revisão geral de segurança para uma pergunta específica e delimitada à qual a TI pode dizer sim.
A mensagem principal do líder é sobre risco, não iniciativa. Não é um novo projeto disputando atenção no orçamento. É reduzir o risco associado a um indicador que a planta já reporta à liderança todas as semanas, que já resultou em uma reclamação de cliente uma vez e cuja repetição seria mais difícil de explicar na segunda vez.
Juntos, esses três pontos convergem para um único pedido: uma alteração na forma como o fluxo de trabalho de rendimento é executado, dando a cada stakeholder exatamente o que a seção anterior descreveu. A TI obtém uma trilha de auditoria, o analista recebe uma verificação agendada e o diretor obtém um número validado.
Testar essa alteração diretamente é a maneira mais rápida de ver se ela se sustenta em um cronograma de produção real. A avaliação gratuita do Alteryx One dura 30 dias, tempo suficiente para criar a verificação, agendá-la e vê-la identificar o próximo turno com problemas antes que ele chegue a um relatório.