O Gartner aponta que 63% das organizações não têm práticas adequadas de gestão de dados para IA, e projeta que cerca de 60% dos projetos de IA sejam abandonados por falta de dado preparado. O número assusta menos quando se entende o que ele quer dizer, porque não é sobre volume de dado. É sobre confiança.
Um agente de IA não inventa qualidade que o dado não tem. Se o cadastro de clientes tem três registros da mesma empresa, o agente vai tratar como três empresas. Se metade dos pedidos não tem data de entrega preenchida, ele não consegue responder prazo. O modelo é bom, o dado é que não está pronto.
Este guia mostra como medir se o seu dado está pronto, antes de contratar qualquer coisa. Ao final você vai ter um retrato por sistema, com nota e com a lista do que precisa ser corrigido primeiro.
O que você precisa antes de começar é acesso de leitura aos sistemas e alguém que saiba exportar uma planilha. Não precisa de engenheiro de dados nesta etapa.
O que quer dizer dado preparado para IA?
Dado preparado é o dado que responde três perguntas sem ambiguidade. Onde ele está, quem é o dono dele, e o quanto dele é confiável. Não tem a ver com estar em nuvem, em banco moderno ou em formato bonito. Uma planilha bem preenchida e com dono claro está mais pronta que um ERP caro com metade dos campos vazios.
A diferença em relação a mapear rotinas é o objeto. Lá você escolhe qual processo vale automatizar, e o critério é retorno. Aqui você já escolheu o processo e está olhando se o dado que ele consome aguenta. Se ainda não escolheu, comece por como mapear as rotinas da empresa antes de automatizar e volte aqui depois.
Os cinco passos
- Localizar em qual sistema mora cada campo que o processo consome.
- Medir quantos por cento dos registros têm esse campo preenchido.
- Medir quantos registros duplicados existem.
- Medir há quanto tempo o dado foi atualizado pela última vez.
- Definir quem é o dono de cada base e quem pode ler o quê.
Passo 1. Localizar o dado que o processo consome
Liste os campos que a tarefa precisa, não as tabelas do sistema. Se o processo é responder prazo de entrega, os campos são número do pedido, status, data prevista e transportadora. Quatro campos, não o banco inteiro.
Para cada campo, anote em qual sistema ele mora. Quando um campo mora em dois sistemas, você achou o primeiro problema, porque em algum momento os dois vão divergir e ninguém vai saber qual está certo.
Passo 2. Medir preenchimento
Exporte os registros dos últimos 90 dias e conte, para cada campo, quantos vieram preenchidos. Percentual simples, sem sofisticação.
A régua prática que usamos é esta. Acima de 95% o campo é utilizável. Entre 80% e 95% o agente precisa saber lidar com a ausência sem inventar. Abaixo de 80% o campo não sustenta automação, e o trabalho anterior é descobrir por que ele não é preenchido.
Quase sempre a resposta é que preencher aquele campo não serve para ninguém hoje, então ninguém preenche. Nesse caso, automatizar em cima dele só vai criar pressão sobre uma equipe que nunca teve motivo para preencher.
Existe um atalho que economiza discussão. Em vez de perguntar ao time se o campo é confiável, mostre o percentual. A conversa muda de opinião para fato, e quase sempre alguém explica na hora por que aquele campo fica vazio em determinado tipo de venda. Essa explicação vale mais que o número.
Passo 3. Medir duplicidade
Duplicidade é o problema mais subestimado de todos. Ordene a base por nome, por documento e por telefone, e olhe. Empresa cadastrada com e sem o sufixo de razão social, com CNPJ formatado de dois jeitos, com telefone com e sem o nono dígito.
Conte quantos grupos duplicados existem e qual percentual da base eles representam. Acima de 5% você tem um problema que precisa ser resolvido antes, porque agente que não sabe quem é quem responde a pessoa errada sobre o pedido errado.
Passo 4. Medir atualidade
Para cada base, veja a data da última atualização de cada registro. O que interessa não é a média, é a cauda. Se 30% dos registros não são tocados há mais de um ano, essa parte da base é histórico, não é operação.
Dado velho não é necessariamente ruim, mas ele precisa ser separado. Um agente que consulta a base inteira vai tratar cliente inativo de 2023 como cliente ativo, e vai responder com informação que não vale mais.
Separe também o que é registro morto do que é registro errado. Cliente que não compra há dois anos é histórico legítimo e pode ficar, desde que marcado. Cliente cadastrado com o nome do vendedor no lugar da razão social é erro, e vai continuar errado depois de qualquer projeto.
Passo 5. Definir dono e acesso
Para cada base, escreva o nome de uma pessoa que responde por ela. Não um departamento, uma pessoa. Base sem dono é base que ninguém corrige.
Depois liste quais campos o agente vai precisar ler, e apenas esses. Essa lista vira a permissão dele. É a diferença entre um agente que consulta status de pedido e um agente que enxerga a margem daquele pedido, e ela é a origem de boa parte dos incidentes que fazem empresas desligarem IA, como mostram os números em o estudo sobre reversão de implementações no Brasil.
Passo 5b. Escrever o que o agente não pode ver
Essa lista é tão importante quanto a de permissão e quase nunca é feita. Escreva explicitamente os campos que o agente não deve enxergar mesmo que estejam na mesma tabela. Margem, custo de aquisição, anotação interna do vendedor sobre o cliente, histórico de negociação de desconto.
O motivo é prático. Quando alguém pedir para o agente resolver mais uma coisa daqui a três meses, essa lista vai ser a única barreira entre o escopo novo e um acesso que ninguém aprovou. Sem ela, a permissão cresce por acúmulo e ninguém percebe.
O retrato final
Junte tudo numa tabela, uma linha por base. O formato que usamos é este.
| Base | Preenchimento | Duplicidade | Atualidade | Dono | Situação |
|---|---|---|---|---|---|
| Pedidos | 97% | 1% | Diária | Definido | Pronta |
| Clientes | 88% | 9% | Mensal | Definido | Corrigir duplicidade |
| Produtos | 72% | 3% | Trimestral | Sem dono | Não usar ainda |
Base marcada como pronta pode entrar no primeiro projeto. Base que precisa de correção entra depois da correção. Base sem dono não entra, porque não há quem responda quando o dado estiver errado.
A conclusão que mais aparece é que a empresa tem uma base pronta e duas quase prontas. Isso é suficiente para começar, e é bem melhor do que esperar todas ficarem perfeitas, o que nunca acontece.
Uma palavra sobre dado sensível
Se alguma das bases guarda dado de saúde, biometria, dado financeiro de pessoa física ou dado de menor de idade, o cuidado muda de patamar. Essas categorias colocam a empresa numa faixa de exposição maior perante a autoridade de proteção de dados, e a decisão sobre usar ou não usar deixa de ser técnica. Marque essas bases no retrato final e trate elas em separado.
Erros comuns
- Querer arrumar tudo antes de começar. Limpeza de dado sem um uso concreto não termina nunca, porque não existe critério para saber quando parou. Escolha o processo primeiro, limpe só o que ele consome.
- Confundir volume com qualidade. Ter dez anos de histórico não ajuda se os últimos três meses estão pela metade. O agente responde sobre hoje, não sobre 2019.
- Medir a média e ignorar a cauda. Preenchimento médio de 90% pode esconder um mês inteiro em branco. Olhe a distribuição, não só o número final.
- Tratar duplicidade como detalhe de cadastro. É o erro que mais gera resposta errada com cara de resposta certa, que é o pior tipo de erro que um agente pode cometer.
- Deixar o dono para depois. Sem dono, a correção que você fizer hoje volta a sujar em três meses, porque nada mudou no processo que gerava a sujeira.
- Pedir para o fornecedor fazer esse diagnóstico. Ele vai fazer, vai cobrar e vai demorar mais, porque não conhece o vocabulário da sua casa. Esta etapa é melhor feita por dentro.
Perguntas frequentes
Quanto tempo leva esse diagnóstico?
Para três ou quatro bases, de dois a quatro dias de trabalho de uma pessoa com acesso de leitura. O que costuma alongar não é a medição, é conseguir a exportação dos sistemas.
Preciso de um data lake ou de uma ferramenta de dados?
Não para começar. Planilha resolve o diagnóstico inteiro. Ferramenta de dado faz sentido quando você já sabe quais bases usa, com que frequência e para quê, e isso é justamente o que este diagnóstico responde.
E se o dado estiver muito ruim?
Aí a primeira entrega do projeto passa a ser a correção, e ela costuma ser mais barata do que parece quando o escopo está limitado aos campos que importam. O erro é gastar meses limpando campo que nenhum processo consome.
Dá para a IA limpar o dado?
Em parte. Padronizar escrita, identificar prováveis duplicados e sugerir preenchimento a partir de outras fontes são tarefas que a IA faz bem. Decidir qual dos dois registros duplicados é o correto continua sendo trabalho de quem conhece o cliente.
Próximo passo
Escolha a base que o seu processo prioritário consome e faça só o passo 2 desta semana. Exporte, conte o preenchimento dos quatro ou cinco campos que importam e olhe o número. Em uma tarde você já vai saber se o seu projeto tem chão ou se ele precisa de uma etapa antes.
Se quiser passar o retrato por quem já viu isso muitas vezes, fale com a gente no WhatsApp, ou veja como isso entra no diagnóstico da metodologia CORE.
2 comentários