Python no BI: de três pesquisas por dia a dezenas

No quarto ano, o trabalho ficou maior do que nós. A área de BI que eu vinha montando numa consultoria de escolas particulares no Brasil já tinha uma base de dados sólida e relatórios refeitos em cima dela (essa parte está em Do Excel ao SQL Server). Só que o volume e a complexidade do trabalho passaram da nossa capacidade de operação. Num dia bom, tratávamos os dados de três pesquisas de clientes. Esse era o teto.

Aquele ano foi decisivo. Este texto conta como quebramos o teto, e por que a resposta foi uma linguagem de programação, e não mais gente.

Para onde iam as horas

Dado de pesquisa quase nunca chega pronto para análise. A pergunta muda de redação de uma edição para outra, as respostas vêm em formatos um pouco diferentes, há respostas incompletas ou repetidas. Antes de chegar a um dashboard, alguém precisa limpar, padronizar e encaixar tudo numa estrutura que os relatórios entendam.

Fazíamos esse tratamento em grande parte à mão. Cada pesquisa repetia muitos dos mesmos passos, e passo repetido à mão tem dois defeitos: é lento e erra num lugar diferente a cada vez. Quanto mais pesquisas chegavam, mais o dia da equipe ia para preparar dado em vez de analisá-lo.

Contratar resolveria por um tempo. Mas quando o gargalo é um procedimento repetitivo, mais gente quase sempre significa mais mãos fazendo o mesmo procedimento repetitivo.

Por que Python

Levei os processos de tratamento de dados para Python, com pandas e numpy. A escolha teve menos a ver com moda do que com uma propriedade: um script faz a mesma coisa toda vez que roda.

O pandas é o burro de carga dos dados em tabela. Lê arquivos e tabelas de banco, limpa, muda o formato, liga uma fonte a outra e agrega o resultado. O numpy fica por baixo e cuida da parte numérica, com rapidez e em grandes volumes. Entre os dois, quase todo passo que fazíamos à mão podia ser escrito uma vez e rodado de novo na pesquisa seguinte.

Em volta deles há um ecossistema grande. matplotlib e seaborn fazem gráficos estáticos e estatísticos, plotly monta gráficos interativos para a web, e os notebooks do Jupyter ajudam a explorar uma base nova e a testar um tratamento antes de ele virar rotina. Ninguém precisa de tudo isso no primeiro dia. No nosso caso, o essencial era tirar o tratamento das mãos das pessoas e passá-lo para o código.

De três pesquisas por dia para dezenas

O efeito foi grande. A automação assumiu a maior parte do processo, a eficiência subiu e o tempo para tratar grandes volumes caiu muito. Passamos de no máximo três pesquisas de clientes tratadas por dia para dezenas.

O que mudou para a equipe pesa tanto quanto o número. As pessoas deixaram de executar o tratamento e passaram a supervisioná-lo. O trabalho delas virou corrigir erros e ajustar perguntas e respostas quando uma pesquisa pedia, justamente a parte que exige critério. O resto andava sozinho.

Essa virada transformou nossa capacidade de operação. E abriu o passo seguinte: com os processos automatizados e a equipe já com quatro pessoas, deu para pensar na experiência do cliente além dos relatórios. Daí veio o quinto ano e um portal web em torno do Power BI Embedded.

Automação vale o que valem as verificações

Automatizar um processo bagunçado só entrega a bagunça mais rápido. Um script que roda dezenas de vezes por dia precisa de proteção, e a qualidade do dado tem de estar no desenho, não numa inspeção no fim. Estas práticas fazem diferença:

• Defina o que é dado bom. Precisão, completude, consistência e atualidade são os critérios de sempre. Escreva o que cada um significa para os seus dados.
• Valide antes de usar. Checagem de valor faltando, resposta impossível e duplicata fica dentro do fluxo, antes de qualquer coisa chegar ao relatório.
• Examine cada lote novo. Uma olhada rápida na estrutura e no conteúdo do que chegou pega surpresas, como uma pergunta renomeada ou uma opção de resposta nova, antes que virem gráfico errado.
• Faça a falha aparecer. Se um passo quebra ou uma checagem não passa, alguém precisa saber na hora, e não descobrir numa reunião com o cliente.
• Dê dono à qualidade. Alguém responde pelas regras, junto com quem é dono da fonte.

Foi aí que ficou o papel humano no nosso caso. Os scripts cuidavam do volume, e as pessoas, das exceções que as verificações apontavam.

Aprender a programar deixou de ser o obstáculo

Não faz muito tempo, aprender uma ferramenta técnica nova era um projeto em si. Isso mudou. Com os assistentes de IA, a curva de aprendizado técnico caiu como eu nunca tinha visto, e falta de tempo para aprender já não justifica ficar longe de uma ferramenta técnica.

Daí saem duas coisas. A IA virou a principal ferramenta de praticamente qualquer trabalho técnico. E a habilidade central de quem trabalha com dados passou a ser aprender: ter fluência para pegar algo novo, passar por cima das dificuldades técnicas e achar soluções melhores. Quem escolhe a ferramenta é a demanda, não a experiência que o analista já tem.

O que eu faria de novo

• Automatize primeiro o passo que mais se repete. No nosso caso, o tratamento das pesquisas.
• Deixe as pessoas onde o critério faz falta. Corrigir erro e ajustar pergunta não é trabalho menor. É a parte que pede alguém que entende a pesquisa.
• Escreva as verificações junto com o fluxo, não depois. Pôr a checagem depois é confiar num período de resultados que ninguém conferiu.
• Não resolva processo repetitivo com contratação. Automatize primeiro e contrate para o trabalho que cresce em cima dele.

A linha do tempo completa desses seis anos está em seis anos montando uma área de BI.

Se uma rotina manual de dados está tomando boa parte da semana da sua equipe, conte para a gente.