Quando trocar planilhas por um sistema na empresa

Existe uma planilha na sua empresa que ninguém pode apagar. Ela tem abas com nomes como "BASE_NOVA_v3_final", fórmulas que atravessam quatro abas, células pintadas de amarelo que significam "aguardando aprovação" e uma pessoa, geralmente uma só, que sabe o que acontece se alguém inserir uma linha no lugar errado.

Essa planilha não é um problema de desorganização. Ela é a prova de que alguém resolveu um problema real sem esperar a TI. O ponto é que chega um momento em que ela deixa de ser ferramenta e passa a ser risco operacional. Este texto é sobre reconhecer esse momento e migrar para um sistema sem jogar fora o que a planilha já ensinou.

A planilha é um protótipo, e isso é bom

Antes de criticar, vale reconhecer o mérito. Uma planilha que a operação usa todo dia é um protótipo de processo já validado. Ela mostra quais dados a empresa realmente precisa, em que ordem eles aparecem, quais cálculos importam e quais exceções acontecem na vida real.

Nenhuma reunião de levantamento de requisitos produz algo tão fiel. Por isso, o erro mais caro numa migração é tratar a planilha como lixo e começar do zero a partir do que as pessoas lembram. O caminho certo é o contrário: usar a planilha como especificação, e o sistema novo como a versão robusta daquilo que ela já faz.

Também vale dizer: nem toda planilha deve virar sistema. Análise pontual, simulação, um cálculo que muda toda semana, um controle usado por uma pessoa só. Planilha é excelente para isso, e continuará sendo.

Sinais de que a planilha virou risco operacional

Os sinais costumam aparecer juntos:

• Versões por e-mail. "Segue a planilha atualizada" circula três vezes por dia, e ninguém sabe qual é a vigente.
• Uma pessoa indispensável. Só ela entende as fórmulas. Quando tira férias, o processo trava ou é feito com medo.
• Dado sem dono. Qualquer um pode alterar qualquer célula, e ninguém sabe quem mudou o valor que estava certo ontem.
• Erro que só aparece no fim. Uma fórmula que deixou de pegar as linhas novas e ninguém percebeu até o fechamento.
• Arquivo lento ou corrompido. A planilha cresceu tanto que abre em minutos e, de vez em quando, perde dados.
• Digitação dupla. A mesma informação é copiada da planilha para o ERP, para o e-mail do cliente e para outra planilha.
• Dados pessoais soltos. CPFs, salários ou dados de clientes circulando em arquivos anexados, sem controle de quem acessa, o que também é uma questão de LGPD.
• Várias pessoas precisam editar ao mesmo tempo, em locais diferentes, e o compartilhamento em nuvem já não resolve os conflitos.

Se dois ou três desses sinais estão presentes num processo que é crítico para a receita, para o caixa ou para a entrega ao cliente, a planilha já não é o lugar certo para ele.

Quando um sistema de mercado resolve

Antes de construir, pergunte se o processo é padrão. Contas a pagar, emissão de nota, folha, CRM comercial simples: existem produtos bons para isso, e às vezes o ERP que a empresa já tem faz, só não foi configurado. A análise mais ampla está em ERP sob medida ou ERP de mercado. Sob medida faz sentido quando a planilha modela algo específico da sua operação: uma regra de precificação, um fluxo de aprovação particular, um controle técnico que nenhum produto cobre.

Lendo abas, fórmulas e cores como especificação

Uma planilha madura é um documento de requisitos escrito em outra linguagem. A leitura cuidadosa revela quase tudo:

Abas são entidades ou etapas. Uma aba de clientes, uma de pedidos, uma de "em andamento" e outra de "concluídos". As primeiras viram cadastros; as últimas, geralmente, viram status de um mesmo registro.

Colunas são campos, e o conteúdo real revela o tipo. Uma coluna de data onde alguém escreve "semana que vem" mostra que o campo precisa de regra, ou de um campo adicional de observação.

Fórmulas são regras de negócio. Cada PROCV, SE aninhado ou soma condicional é uma regra que precisa ser entendida, nomeada e testada. É comum descobrir fórmulas inconsistentes entre linhas, e isso é informação valiosa: ou a regra tem exceções, ou há um erro que ninguém viu.

Cores e formatação são estados. Linha vermelha é atrasado, amarela é pendente, verde é aprovado, tachado é cancelado. No sistema, isso vira status explícito, com regra de transição e registro de quem mudou.

Comentários e observações são exceções. A coluna "OBS" é onde mora o que o processo formal não previu. Ler todas elas mostra os casos que o sistema precisa tratar, ou decidir conscientemente não tratar.

Macros são automações. Se existe VBA, ele é código de verdade e precisa ser lido como tal.

O resultado dessa leitura é um mapa: entidades, campos, regras, estados e exceções. É dele que sai o desenho do sistema, validado depois com quem usa a planilha todos os dias.

Quem edita o quê: permissões e histórico

A planilha tem um modelo de permissão binário: ou você tem o arquivo, ou não tem. O sistema permite o que o processo sempre precisou e nunca teve:

• Perfis por função. Quem lança, quem aprova, quem só consulta.
• Escopo por unidade ou carteira. A filial vê os próprios registros; o gestor vê a equipe.
• Campos protegidos por etapa. Depois de aprovado, o valor não muda sem um novo fluxo.
• Histórico de alterações. Quem mudou, quando, de qual valor para qual valor.
• Trabalho simultâneo sem conflito de versão.

É essa camada, mais do que as telas, que elimina o risco. Um valor que muda sem autor deixa de existir.

Migrando os dados sem perder o passado

O histórico que está na planilha tem valor: é ele que permite comparar desempenho, responder auditoria e entender tendências. A migração precisa de cuidado:

1. Congele uma cópia da planilha no estado atual antes de qualquer tratamento.
2. Normalize os dados. Nomes com grafias diferentes, datas em formatos variados, valores digitados como texto. Cada limpeza vira uma regra documentada.
3. Decida o que migra completo. Registros em aberto entram integralmente. Histórico antigo pode entrar simplificado ou ficar disponível como consulta.
4. Faça ensaios de carga e peça para quem usa a planilha conferir amostras.
5. Defina a data da virada. A partir dela, a planilha fica somente leitura. Dois lugares editáveis ao mesmo tempo produzem divergência garantida.

O que continua na planilha, de propósito

Um sistema que tenta eliminar toda planilha costuma falhar. As pessoas voltam para o Excel porque precisam de flexibilidade para análises que o sistema não previu. A saída é planejar essa convivência:

• Exportação limpa dos dados do sistema, com colunas estáveis, para quem quer analisar à vontade.
• Relatórios e painéis para as perguntas recorrentes. Se a mesma análise é refeita toda semana, ela merece virar painel; a escolha entre construir um próprio ou usar uma ferramenta está em dashboard personalizado ou Power BI.
• Planilha como ferramenta de simulação, alimentada pelo sistema, mas sem devolver dados para ele.

A regra é simples: o sistema é a fonte da verdade; a planilha é uma ferramenta de análise. O dado nasce e muda no sistema. A planilha lê.

Primeiro passo: um processo, não a empresa toda

A tentação é mapear todas as planilhas e construir um sistema que substitua todas. Esse projeto é longo, arriscado e tende a perder o apoio de quem mais precisa dele.

O caminho que funciona é escolher um processo com dor clara e fronteira definida. Um bom candidato é aquele em que a planilha causa erro visível, depende de uma pessoa só e envolve mais de um setor. Um exemplo comum é o fluxo de compras: requisição por e-mail, cotação numa planilha, aprovação por mensagem. É o tipo de processo que um sistema de cotação e compras organiza de ponta a ponta.

Para esse primeiro processo, defina uma versão enxuta que já substitua a planilha no dia a dia, sem tentar cobrir todas as exceções logo de início. O método para fazer esse corte está em como definir o escopo de um MVP.

Riscos e erros comuns

• Reproduzir a planilha tela por tela. O resultado é uma planilha mais lenta, sem a flexibilidade que as pessoas gostavam.
• Ignorar quem mantém a planilha. A pessoa que criou o controle é a melhor fonte de requisitos e a principal aliada da adoção.
• Excesso de campos obrigatórios. Cada obrigatoriedade sem motivo empurra o usuário de volta para o Excel.
• Não migrar o histórico e perder a capacidade de comparação.
• Deixar a planilha viva em paralelo depois da virada.

Como medir se deu certo

Meça a linha de base antes de começar e compare depois de alguns ciclos de uso:

• Tempo para concluir o processo, do início ao fim.
• Retrabalho e correções de erro por período.
• Quantidade de lugares onde o mesmo dado ainda é digitado.
• Dependência de uma pessoa específica para executar o processo.
• Existência de planilhas paralelas meses depois do lançamento. Se elas voltaram, o sistema ainda não resolve algo que a equipe precisa, e vale descobrir o quê.

Checklist antes de começar

• O processo é crítico e tem dor mensurável?
• Existe um produto de mercado que resolveria sem desenvolvimento?
• As fórmulas, cores e observações foram lidas e mapeadas?
• Está claro quem lança, quem aprova e quem só consulta?
• Há um plano para migrar o histórico e congelar a planilha?
• Foi definido o que continua em planilha, de propósito?

Da planilha ao sistema, sem perder a agilidade

Na Pervian Tech, trocar uma planilha por um sistema começa lendo a planilha com respeito: cada aba, fórmula e cor é tratada como requisito, e quem a mantém participa do desenho. O sistema nasce sob medida para aquele processo, com permissões, histórico e exportação para quem ainda quer analisar no Excel. Veja como trabalhamos em desenvolvimento web sob medida.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que entendemos o processo e o tamanho da planilha. Se existe na sua empresa aquela planilha que ninguém pode apagar, mostre para a gente.