Limpeza de dados de comércio exterior: um caso real

A realidade foi bem diferente. O que encontramos pelo caminho nos obrigou a repensar a solução técnica, a questionar premissas sobre a infraestrutura em nuvem e, sobretudo, a entender algo fundamental: quando os dados são inseridos por pessoas, o verdadeiro desafio não é tecnológico, é humano.

A tarefa de limpar e organizar dados de comércio exterior pode parecer simples, mas, diante da realidade de vários países e nenhum padrão, torna-se um desafio significativo. Foi esse o desafio que a Arcetec enfrentou ao trabalhar com dados aduaneiros de sete países latino-americanos para permitir que uma multinacional de bens de consumo tomasse melhores decisões de compra.

O desafio: sete países, seis produtos, dados heterogêneos

Nosso cliente precisava de visibilidade sobre o comportamento de importação e exportação de seis produtos-chave. As informações existiam nos registros aduaneiros de cada país, mas cada nação tinha sua própria estrutura de dados, seus próprios campos e suas próprias regras de reporte.

O maior desafio estava nos campos de texto livre. As descrições aduaneiras são escritas por pessoas, com abreviações, erros de digitação e formatos que variam de um operador para outro. Às vezes, a informação relevante não estava em um único campo, mas dispersa em descrições complementares que precisavam ser concatenadas para encontrar padrões úteis.

E havia uma complexidade adicional: os cálculos necessários e as colunas de saída mudavam conforme o produto e o país. Não estávamos construindo um pipeline único, mas um sistema capaz de se adaptar a múltiplos esquemas de entrada e saída simultaneamente.

Primeiro desafio: implantar na nuvem

O plano original era implantar a solução no Google Cloud Platform. Parecia a decisão lógica: escalável, robusta, automatizável. Mas dois fatores nos frearam rapidamente.

Primeiro, as restrições do ambiente do cliente limitavam as ferramentas disponíveis no GCP. Não tínhamos total liberdade para escolher serviços, o que reduzia nossas opções de arquitetura. Segundo, tínhamos desenvolvido com uma pequena amostra de dados e, quando processamos o histórico completo, a infraestrutura não deu conta.

Essa é uma lição que vemos se repetir em muitos projetos: a amostra de desenvolvimento nem sempre revela os problemas de escala. E descobrir isso tarde tem um custo alto em tempo e em expectativas.

Segundo desafio: dados de entrada e saída variáveis

O que não se previa, embora a proposta comercial já contemplasse que os dados de entrada teriam formatos diferentes, era que, ao iniciarmos o levantamento e o Discovery, descobriríamos que os esquemas de saída também variavam. Ou seja, não só tínhamos dados de entrada com esquemas diferentes por país, como também teríamos esquemas de saída com cálculos específicos por produto, o que acrescentou uma camada importante de complexidade.

Na prática, isso significava que um mesmo pipeline não servia para todos os casos. Cada combinação de país e produto podia gerar um esquema de saída diferente, com colunas adicionais, cálculos específicos e regras de validação próprias. Projetar uma solução rígida teria implicado reescrever a lógica sempre que surgisse um novo cenário, algo insustentável em um processo que precisava ser executado automaticamente todo mês.

Terceiro desafio: informações-chave presas em campos de texto aberto

As informações mais importantes para a categorização e os cálculos não estavam em campos estruturados. Estavam dentro de descrições aduaneiras redigidas por pessoas e, em muitos casos, distribuídas em mais de um campo de texto livre.

Para ilustrar: uma descrição podia dizer "RLL PPL HIG BL 40M X30 DBL HJ" e, a partir disso, o sistema precisava deduzir produto, cor, metragem, quantidade de unidades por pacote e tipo de folha. Mas o registro seguinte do mesmo produto podia estar escrito de forma completamente diferente, com outras abreviações ou com a informação distribuída entre o campo de descrição principal e um campo complementar que precisava ser concatenado.

É nesse ponto que a influência humana na entrada de dados fica mais evidente. Não existe um padrão real entre operadores aduaneiros de países diferentes nem, muitas vezes, entre operadores do mesmo país. Cada pessoa escreve do seu jeito, abrevia como acha melhor e, às vezes, omite informações que são críticas para a análise. Qualquer regra de extração que projetássemos tinha de considerar essa variabilidade como a norma, não como a exceção.

A virada: quando o plano de contingência supera o plano original

Diante das limitações no GCP, a equipe havia projetado em paralelo um sistema de informação alternativo, pensado inicialmente apenas para validar os volumes de dados históricos. Era uma ferramenta de apoio, não a solução principal.

No entanto, à medida que o aperfeiçoamos, esse sistema demonstrou capacidades que a solução em nuvem não oferecia: permitia que o usuário de negócio configurasse parâmetros diretamente na ferramenta para ajustar as regras de transformação sem depender da equipe técnica a cada mudança. Além disso, incorporou visualização em dashboards, algo que o escopo original não contemplava.

Tomar a decisão de mudar de rumo não foi simples. Significou reavaliar escopo, prazos e expectativas com o cliente. Mas o resultado foi uma solução mais completa, mais autônoma para o usuário final e, no fim das contas, superior ao que havíamos concebido originalmente.

O que este projeto nos ensinou

Reflexão final

Por trás de cada dado há uma decisão humana: alguém que escreveu uma descrição em uma alfândega, alguém que escolheu um formato, alguém que abrevia de um jeito particular. A tecnologia que construímos precisa ser inteligente o bastante para entender essa variabilidade, e não para ignorá-la.

Na Arcetec, continuamos trabalhando com empresas que enfrentam esse tipo de desafio: transformar dados dispersos e desorganizados em informações claras que impulsionem decisões. Se a sua organização está lidando com dados de múltiplas fontes, múltiplos países ou múltiplos formatos, vamos adorar conversar.