Substituir planilha por sistema: quando o painel compensa

O resumo direto

Painel interno sob medida é um sistema web pequeno, feito para um processo da própria empresa, com banco de dados, login por pessoa e regras que o sistema aplica sozinho; vale quando uma planilha compartilhada passou a ter várias pessoas editando o mesmo dado e o erro custa dinheiro. A planilha não quebra por ser grande. Ela quebra em quatro pontos: edição concorrente, histórico que não explica nada, permissão que não separa pessoas e regra de negócio que ninguém confere na entrada. O hub de sistemas sob medida mostra onde esse painel entra em relação a outros projetos. O corte para trocar não é faturamento nem número de funcionários: é quantas pessoas escrevem na mesma planilha e quanto custa um valor errado passar adiante. Abaixo, como reconhecer cada ponto de quebra, o critério de corte e o que levantar antes de pedir um painel.

Qual sistema substitui o Excel?

Não é um programa único que substitui o Excel em qualquer empresa. Para um processo operacional, o substituto costuma ser um painel interno sob medida ou uma ferramenta pronta com banco, usuários e permissões. A escolha depende da regra que precisa ser aplicada, dos sistemas que já existem e da necessidade de cada pessoa ver apenas os dados do seu papel.

O Excel continua útil como planilha de análise, importação e exportação. Ele deixa de ser uma boa fonte oficial quando o mesmo registro passa por vendas, estoque, financeiro e expedição, porque a célula não representa a operação inteira. Nesse ponto, o sistema deve guardar o dado central, bloquear combinações inválidas e registrar quem fez cada mudança.

1. Os quatro pontos em que a planilha compartilhada quebra

Planilha é uma ferramenta excelente para uma pessoa pensar. Os problemas começam quando ela vira o sistema de um processo inteiro, com gente de setores diferentes escrevendo nela o dia todo. O Google Planilhas e o Excel têm recurso para cada um dos problemas abaixo. O que falta não é recurso: é o recurso ser obrigatório e não depender da boa vontade de quem edita.

Cada linha dessa tabela vira uma seção. A pergunta em todas é a mesma: quando a regra falha, quem percebe, e quando.

2. Edição concorrente: o problema não é o arquivo, é a operação

A coautoria resolveu o problema antigo do "arquivo bloqueado para edição". Hoje várias pessoas abrem a mesma planilha e digitam ao mesmo tempo. No Excel, a documentação da Microsoft condiciona isso a guardar o arquivo no OneDrive ou no SharePoint Online e a usar versões compatíveis com coautoria. No Planilhas, é o comportamento padrão.

O que a coautoria não resolve é que um processo de negócio raramente é uma célula. "Separar o pedido" mexe no status, na quantidade reservada, na data de expedição e às vezes no saldo de estoque de outra aba. A planilha sincroniza cada célula isoladamente. Ela não sabe que aquelas quatro células formam uma operação só.

Como isso aparece no dia a dia

• Duas pessoas reservam a última unidade do mesmo item, cada uma numa linha, porque o saldo só atualiza depois que a fórmula recalcula.
• Alguém ordena a aba inteira enquanto outra pessoa está digitando, e o valor digitado cai na linha errada.
• Um filtro aplicado por uma pessoa esconde linhas que outra pessoa está conferindo, e a conferência termina "sem pendências".
• Uma fórmula arrastada até o fim da coluna é apagada por quem cola dados por cima.

Nenhum desses casos é descuido de uma pessoa específica. É o resultado previsível de várias pessoas escrevendo numa estrutura que não tem conceito de transação.

O que um banco de dados faz diferente

Num painel com banco relacional, "separar o pedido" é uma transação: ou todas as alterações entram, ou nenhuma entra. Se duas pessoas tentam reservar a última unidade, o banco serializa as duas tentativas e a segunda recebe um erro claro em vez de um saldo negativo silencioso. Ordenar e filtrar viram coisas da tela de cada pessoa, sem alterar o dado dos outros.

3. Histórico: saber que mudou não é saber por quê

O histórico de versões do Google Planilhas mostra versões anteriores, quem editou e permite restaurar. É um recurso bom para desfazer um estrago. Para operar um processo, ele tem dois limites.

O primeiro é granularidade. Restaurar uma versão desfaz tudo o que aconteceu depois dela, inclusive o trabalho correto de outras pessoas. Na prática, ninguém restaura: alguém compara versões na mão e corrige célula por célula.

O segundo é contexto. O histórico registra que a célula passou de "pendente" para "pago". Ele não registra em nome de qual pedido, a partir de qual comprovante, nem se a pessoa que alterou tinha função para dar baixa em pagamento. Quando a pergunta é "quem autorizou isso?", a planilha responde só "quem digitou".

O que conta como histórico útil

Histórico útil responde a quatro perguntas sem ninguém precisar abrir versões antigas: o que mudou, de qual valor para qual valor, quem mudou e por qual ação do sistema. Isso vira uma tabela de auditoria no banco. A própria documentação do PL/pgSQL, do PostgreSQL, traz um exemplo de função de gatilho que grava em tabela separada cada inclusão, alteração e exclusão, com o usuário e o horário.

CREATE TRIGGER auditar_pedidos
AFTER INSERT OR UPDATE OR DELETE ON pedidos
FOR EACH ROW EXECUTE FUNCTION registrar_auditoria();

A diferença para o histórico da planilha: o registro nasce junto com a alteração, pela mesma porta, e editar o dado pelo sistema deixa rastro por definição.

4. Permissão por pessoa: proteger célula não é controlar acesso

No Google Planilhas é possível proteger uma página ou um intervalo e escolher quem pode editá-lo, ou apenas exibir um aviso a quem tentar. No Excel existe a proteção de planilha com senha. As duas funcionam para evitar que alguém apague uma fórmula sem querer. Nenhuma das duas foi feita para separar o que cada pessoa pode ver.

A Microsoft é direta na documentação: a proteção de planilha do Excel não é um recurso de segurança. Ela impede alterar células bloqueadas, e só. No Planilhas, a proteção controla edição; quem tem acesso ao arquivo continua vendo o conteúdo das abas.

Onde isso vira problema

• O vendedor precisa ver os próprios pedidos, mas a planilha é uma só e mostra a comissão de todo mundo.
• O financeiro precisa dar baixa em pagamento, mas a mesma planilha deixa o estoque editar o campo "pago".
• Um prestador externo precisa atualizar o status de entrega e, para isso, recebe acesso ao arquivo inteiro, com dado de cliente.

O terceiro caso tem peso legal. A LGPD exige, no art. 46, medidas técnicas e administrativas para proteger dados pessoais contra acessos não autorizados. Compartilhar a planilha inteira para alguém editar uma coluna é difícil de defender como medida adequada.

Como o painel resolve

No painel, permissão é por papel e, quando precisa, por linha. O vendedor vê os pedidos dele; o financeiro vê o campo de pagamento e mais nada; o prestador vê só as entregas atribuídas a ele. O PostgreSQL faz isso no próprio banco com Row Level Security, e a documentação descreve o comportamento padrão quando não há política definida: "a default-deny policy". Ou seja, o banco nega por padrão e libera o que foi explicitamente permitido. É o contrário da planilha, que libera tudo e tenta proteger pedaços.

5. Regra de negócio na entrada: a validação que só avisa

A validação de dados do Planilhas tem duas opções para quando o dado é inválido: mostrar um aviso ou rejeitar a entrada. Muita planilha operacional está configurada no aviso, porque em algum momento alguém precisou "só passar esse caso" e a rejeição atrapalhou. A partir daí, a regra é sugestão.

Mesmo configurada para rejeitar, a validação vale para a célula. Ela confere se a data é uma data, se o valor está numa lista. Ela não sabe que a data de entrega não pode ser anterior à data do pedido, que desconto acima de certo teto precisa de aprovação, ou que um pedido cancelado não pode receber baixa de pagamento. Essas regras vivem na cabeça de quem opera e, com sorte, num documento que ninguém abre.

A regra no lugar certo

Num painel, a regra de negócio fica em dois lugares. Na tela, para orientar quem digita. No banco, para recusar o que passou pela tela por qualquer caminho: importação, integração, correção manual. A documentação do PostgreSQL é objetiva: ao tentar gravar um valor que viola uma restrição, "an error is raised".

ALTER TABLE pedidos
  ADD CONSTRAINT entrega_depois_do_pedido
  CHECK (data_entrega >= data_pedido);

Com isso, a regra deixa de depender de alguém lembrar dela. O dado errado não entra, e a mensagem de erro diz por quê.

6. O corte: quantas pessoas editam e quanto custa o erro

O critério que mais aparece em conversa é tamanho: "quando a empresa crescer, a gente faz um sistema". Tamanho é um indicador ruim. Uma empresa grande pode ter uma planilha que só o controller edita, e ela funciona. Uma empresa pequena pode ter uma planilha de pedidos editada por vendas, estoque, expedição e financeiro, e ela já é o gargalo.

Duas variáveis decidem melhor:

1. Quantas pessoas escrevem no mesmo dado. Uma pessoa editando e várias lendo é uso saudável de planilha. Várias pessoas escrevendo nas mesmas linhas é onde os quatro pontos de quebra aparecem juntos.
2. Quanto custa um valor errado passar adiante. Erro que alguém percebe logo e corrige na hora é barato. Erro que vira pedido faturado errado, estoque furado, baixa de pagamento duplicada ou dado de cliente exposto é caro, e costuma ser descoberto tarde.

A última linha da tabela é onde o painel se paga. Não por ganho de produtividade que alguém consiga prometer em número, mas porque cada erro evitado ali tem custo direto e mensurável pela própria empresa: nota cancelada, frete refeito, cliente reembolsado, horas de conferência.

7 sinais de que a planilha travou

1. Existe uma pessoa cuja função informal é "arrumar a planilha".
2. Há cópias da planilha por setor, e a reunião serve para reconciliar as cópias.
3. Alguém já perguntou "quem mudou isso?" e a resposta foi comparar versões antigas.
4. A planilha tem aba chamada "não mexer".
5. Uma fórmula ou filtro alterado muda o resultado para todo mundo.
6. O mesmo pedido precisa ser digitado em mais de um arquivo.
7. Ninguém consegue explicar qual versão é a fonte oficial do dado.

Sistema interno para empresa: o que entra num painel

"Painel" às vezes é confundido com dashboard de gráficos. Aqui o sentido é outro: é a ferramenta onde a operação acontece, com gráficos como consequência. Um painel interno sob medida bem feito tem, no mínimo:

• Banco de dados relacional com as regras de negócio como restrições, para que o banco recuse o dado inválido venha ele da tela, de importação ou de integração.
• Login individual e papéis (vendas, estoque, financeiro, externo), com permissão por tela, por campo e, quando precisa, por linha.
• Trilha de auditoria automática: o que mudou, de quanto para quanto, quem e quando.
• Telas por tarefa, não por tabela: "separar pedido", "dar baixa", "registrar devolução", cada uma mexendo só no que a tarefa exige.
• Importação e exportação para planilha, porque a planilha continua ótima para análise pontual. A diferença é que ela passa a ser saída, não fonte.

Custo e prazo dependem do escopo, principalmente de integração com outros sistemas, granularidade de permissão e auditoria. Se o painel também abastecer um front público, o artigo sobre WordPress headless ajuda a separar operação e apresentação.

Quanto custa trocar a planilha por um sistema?

Não há preço responsável sem conhecer o processo. Integração, permissão, auditoria e migração dos dados mudam mais o escopo que a quantidade de telas. O artigo Quanto custa desenvolver um sistema web sob medida detalha como comparar proposta e custo de operação, sem transformar uma estimativa em promessa.

8. Como levantar o processo antes de pedir o painel

O insumo mais útil para um orçamento honesto é a planilha atual com o processo descrito em volta dela. Antes de conversar com quem vai desenvolver, vale anotar:

• Quem edita e o quê. Lista de pessoas ou funções e quais colunas cada uma altera no dia a dia.
• As regras que hoje vivem na cabeça. "Desconto acima de tanto precisa de aprovação", "pedido cancelado não pode ter baixa", "só o financeiro marca como pago".
• Os erros que já aconteceram. Alguns casos concretos, com o que custou cada um. Eles mostram onde a regra precisa estar no banco.
• Com o que a planilha conversa. ERP, loja virtual, banco, e-mail, outra planilha. Cada integração é escopo.
• Quem precisa ver sem editar. Diretoria, contador, prestador externo.

Com isso em mãos, dá para separar o que é essencial na primeira versão do que pode esperar. Painel interno não precisa nascer cobrindo o processo inteiro: começar pela parte onde várias pessoas escrevem e o erro é caro já tira a planilha do caminho crítico.

Perguntas frequentes

Não dá para resolver com Apps Script ou macro na própria planilha?

Dá para automatizar tarefas e reforçar algumas regras. O limite continua o mesmo: quem tem permissão de edição no arquivo consegue contornar a regra editando a célula direto, e a planilha segue sem transação e sem permissão por linha. Script é bom paliativo quando o problema é repetição; não resolve quando o problema é várias pessoas escrevendo no mesmo dado com erro caro.

Uma ferramenta no-code não resolve o mesmo problema?

Em muitos casos, sim, e vale considerar antes de um painel sob medida. Ferramentas no-code com banco por trás já trazem login por pessoa e algum controle de permissão. O corte costuma aparecer quando a regra de negócio é específica demais para a ferramenta, quando a permissão precisa descer ao nível da linha ou quando há integração com ERP ou loja que a ferramenta não cobre.

A equipe vai perder a flexibilidade da planilha?

Perde a flexibilidade de mudar o processo sem ninguém saber, que é justamente o que gera o erro. A flexibilidade de análise continua: o painel exporta para planilha, e qualquer pessoa pode montar a tabela dinâmica que quiser em cima de um dado que agora é confiável.

O painel substitui o ERP?

Não é o objetivo. O painel cobre o processo que o ERP não cobre ou cobre mal, e que por isso foi parar na planilha. Quando há ERP, o painel lê e grava nele por integração, em vez de duplicar cadastro.

Conclusão

A planilha compartilhada vira gargalo quando várias pessoas escrevem no mesmo dado e o erro custa caro, não quando a empresa cresce. Os sintomas se repetem: edição que sobrescreve, histórico que não explica, permissão que não separa e regra que só avisa. Um painel interno sob medida resolve os quatro pondo as regras no banco, e não na memória de quem opera. Se esse é o seu caso, manda em oailton.dev/contato o processo que roda na planilha hoje e quantas pessoas editam a planilha, que eu digo se é caso de painel, de ajuste na própria planilha ou de ferramenta pronta.

Para ver como conduzo projetos de sistema sob medida, da descoberta à manutenção, a página Sistemas resume o serviço e o portfólio mostra casos entregues.