A planilha de 47 abas que ninguém deveria ter visto
Era uma terça-feira comum numa empresa de logística com 340 funcionários. O diretor de operações chamou o gestor de TI para uma reunião rápida. “Preciso que você veja uma coisa”, disse, virando o monitor.
Na tela, uma planilha de Excel com 47 abas. Cada aba representava um processo operacional que, teoricamente, deveria acontecer dentro do sistema de gestão que a empresa pagava R$ 18.000 por mês. Pedidos, roteirização, controle de frota, conferência de entregas. Tudo ali. Fora do sistema.
“Quem fez isso?”, perguntou o diretor.
A resposta foi desconfortável: “A equipe de operações. Eles montaram isso ao longo dos últimos dois anos. Disseram que o sistema não deixa fazer o que eles precisam no dia a dia.”
O gestor de TI ficou em silêncio. Não porque não sabia da planilha. Sabia. Todo mundo sabia. Mas ninguém tinha parado para perguntar a pergunta certa: por que 340 pessoas preferem uma planilha de Excel a um sistema de R$ 216.000 por ano?
Se essa cena soa familiar — se você já ouviu algo como “ah, mas a equipe usa uma planilha por fora” ou “eles têm um jeitinho próprio de fazer” — você não tem um problema de segurança. Você tem um problema de produto. E ele está custando mais do que você imagina.
Shadow IT não é rebeldia. É sobrevivência cognitiva.
A definição clássica de Shadow IT é qualquer tecnologia usada dentro de uma organização sem aprovação formal da equipe de TI. Planilhas compartilhadas por e-mail. Grupos de WhatsApp para coordenação operacional. Ferramentas de IA generativa acessadas com conta pessoal. Bots construídos no Python do analista júnior.
Segundo a Gartner, mais de 80% das empresas convivem com algum grau de Shadow IT. A narrativa tradicional trata isso como risco: risco de segurança, risco de compliance, risco de dados. E sim, esses riscos existem. Mas tratar Shadow IT apenas como problema de segurança é como tratar febre com antitérmico sem investigar a infecção.
A febre não é a doença. É o sintoma.
Depois de 17 anos construindo sistemas de gestão e SaaS B2B, eu já vi esse padrão se repetir dezenas de vezes. E posso afirmar com segurança: Shadow IT é a manifestação mais concreta e mensurável de fricção de produto que existe. É o usuário dizendo, com ações, aquilo que ele não consegue articular num ticket de suporte: “Este sistema não me ajuda a fazer meu trabalho. Então eu construí meu próprio caminho.”
E aqui está o dado que deveria tirar o sono de qualquer Product Manager: a pesquisa em comportamento organizacional mostra que a criação de soluções alternativas — planilhas não autorizadas, processos paralelos, gambiarras operacionais — está diretamente associada a baixa adesão, sabotagem silenciosa e erosão de confiança no sistema. Como aponta a literatura sobre confiança em ecossistemas de software: “Comportamentos disfuncionais (planilhas paralelas, sabotagem silenciosa) emergem como resposta à baixa confiança no sistema”. O usuário não abandona o sistema de uma vez. Ele o abandona em silêncio, funcionalidade por funcionalidade, até que o sistema vira um elefante branco que ninguém usa de verdade.
E quando chega o momento da renovação de contrato, adivinha o que acontece?
A neurociência explica: o cérebro não aceita fricção — e ponto final
Para entender por que Shadow IT é tão prevalente, precisamos olhar para como o cérebro humano lida com esforço. E aqui a ciência é clara, replicada e inquestionável.
A Teoria da Carga Cognitiva, desenvolvida por John Sweller, postula que a memória de trabalho humana tem capacidade finita. Existem três tipos de carga:
- Intrínseca: a complexidade inerente da tarefa (ex: calcular imposto sobre folha de pagamento).
- Extrínseca: a complexidade imposta pela forma como a informação é apresentada (ex: menu com 3 níveis, formulário mal estruturado, fluxo de 12 passos).
- Germânica: o esforço produtivo dedicado à construção de modelos mentais duradouros (ex: aprender um padrão que vai se repetir).
Um bom design de UX minimiza a carga extrínseca e maximiza a carga germânica. Steve Krug sintetizou isso em seu famoso princípio: “Não me faça pensar”. Se o usuário precisa de instruções, treinamento presencial ou uma planilha paralela para realizar uma tarefa, o design falhou em minimizar a carga cognitiva extrínseca.
E é exatamente o que o usuário faz quando cria uma planilha paralela. Ele não está sendo “rebelde”. Ele está reduzindo carga cognitiva. A planilha é simples. Ele controla. Ele entende. Não precisa de 7 cliques para fazer o que precisa. Não precisa pedir permissão. Não precisa esperar o sistema carregar.
O pesquisador Nir Eyal aplica a Teoria Dual Process de Kahneman diretamente ao design de produtos. O cérebro opera em dois modos: o Sistema 1 (rápido, intuitivo, automático) e o Sistema 2 (lento, analítico, esforçado). Um sistema com alta fricção força o usuário a operar permanentemente no Sistema 2 — o modo que consome energia, cansa e gera frustração.
A planilha paralela, por outro lado, opera no Sistema 1. É familiar. É automática. Não exige decodificação.
Quando você coloca um usuário diante da escolha entre “usar o sistema oficial que exige 12 passos e 3 minutos” versus “abrir a planilha que resolve em 30 segundos”, o cérebro já decidiu antes mesmo de o usuário perceber. E ele vai escolher a planilha. Sempre.
Isso não é um problema de treinamento. Não é um problema de adoção. É um problema de design. E é um problema que a maioria das empresas de SaaS B2B no Brasil simplesmente se recusa a enxergar.
Os 3 tipos de Shadow IT (e o que cada um revela sobre seu produto)
Nem todo Shadow IT nasce pelo mesmo motivo. Classificar o tipo ajuda a diagnosticar a fricção raiz. E aqui está uma taxonomia que desenvolvi ao longo de anos de diagnóstico em sistemas de gestão:
Tipo 1: A Planilha de Compensação de Insight
Sintoma: O usuário usa o sistema para registrar dados, mas exporta tudo para Excel para fazer análises, cruzamentos ou relatórios que o sistema não permite.
O que revela: O sistema coleta dados, mas não devolve insight. A arquitetura de informação é orientada a registro, não a resultado. O usuário precisa do dado, mas não consegue extraí-lo de forma útil dentro do próprio produto.
A fricção: Ausência de dashboards configuráveis, relatórios flexíveis ou visibilidade de dados. O produto não mostra ao usuário o impacto do próprio uso. Ele é um “coletor cego” de informação.
Exemplo típico: Uma empresa de serviços que registra 10.000 atendimentos por mês no CRM, mas precisa exportar para Excel toda semana para gerar um relatório de “atendimentos por tipo de problema por região”. O CRM tem os dados. Mas não tem a visão.
Tipo 2: O Workflow Paralelo de Execução
Sintoma: O usuário ignora fluxos inteiros do sistema e recria o processo operacional fora dele — em planilhas, em ferramentas de automação, em grupos de mensagem.
O que revela: O fluxo do sistema não corresponde ao fluxo real de trabalho. A arquitetura foi construída feature a feature, sem mapeamento de jornada do usuário. O usuário precisa de 7 telas e 12 cliques para fazer algo que, na prática, é uma tarefa linear.
A fricção: Navegação confusa, excesso de passos, falta de automação. O sistema foi desenhado para a estrutura do banco de dados, não para o fluxo de trabalho do humano.
Exemplo típico: Uma equipe de logística que precisa registrar a saída de um caminhão. No sistema oficial, isso exige: login → menu “operações” → submenu “frota” → botão “nova saída” → formulário de 18 campos → confirmação → voltar ao menu. Na planilha, é: abrir o arquivo → preencher 4 células → salvar.
Tipo 3: A Gambiarra de Integração
Sintoma: O usuário conecta o sistema a outras ferramentas usando soluções improvisadas — scripts, extensões de navegador, IFTTT, Zapier com conta pessoal, APIs acessadas via Postman.
O que revela: O sistema é um silo. Não conversa com o ecossistema do cliente. O usuário precisa de integração, mas ela não existe oficialmente — ou é tão complexa de configurar que ele prefere improvisar.
A fricção: Falta de integrações nativas, APIs mal documentadas, ou processos de configuração que exigem conhecimento técnico que o usuário operacional não tem.
Exemplo típico: Uma equipe de marketing que precisa enviar dados do CRM para o Mailchimp, mas a integração oficial é cara e limitada. O analista cria um script em Python que roda toda noite num notebook pessoal, exportando CSV e importando manualmente.
O custo real: não é segurança. É churn silencioso.
Aqui está o ponto que muda a conversa. O custo do Shadow IT não é o risco de um vazamento de dados (embora isso exista e seja sério). O custo real é a erosão silenciosa da relação entre o usuário e o produto.
Vamos pensar no ciclo completo:
- O usuário encontra fricção no sistema (fluxo confuso, lentidão, falta de funcionalidade).
- Em vez de abrir um ticket (que talvez não resolva), ele cria um workaround.
- O workaround funciona. O usuário para de usar aquela parte do sistema.
- Com o tempo, mais partes do sistema são abandonadas. O uso real cai.
- Na hora da renovação, o decisor olha para o sistema e pergunta: “Estamos usando isso de verdade?”
- A resposta é não. O cancelamento acontece.
A pesquisa da Gainsight já demonstrou que 67% do churn no setor SaaS está correlacionado com baixa adoção do produto — não com preço, não com concorrência. E Shadow IT é a manifestação mais concreta de baixa adoção. O usuário está fisicamente presente (loga, registra, clica), mas funcionalmente ausente.
Além disso, há o custo operacional direto. Se a equipe precisa manter duas fontes de verdade (o sistema + a planilha), cada tarefa é feita duas vezes. Cada conferência exige cruzamento. Cada erro de sincronização gera retrabalho. A produtividade cai. E quando a produtividade cai, o sistema é percebido como obstáculo, não como ferramenta.
Segundo dados compilados pela Reuters sobre sobrecarga de informação, a fragmentação de ferramentas afeta negativamente as decisões de negócio e o bem-estar dos funcionários: 43% dos entrevistados relataram decisões atrasadas devido à “paralisia analítica” e 66% associaram a sobrecarga à tensão entre colegas.
Shadow IT não é apenas um problema de TI. É um problema de produtividade, de moral e, finalmente, de retenção.
A matemática do custo oculto: quanto Shadow IT está te custando?
Vamos transformar isso em número, porque número é o que convence CFO.
Cenário realista (empresa de SaaS B2B com 200 clientes enterprise):
Custo direto de Shadow IT por cliente:
- 10 horas/mês de trabalho duplicado (sistema + planilha) × R$ 80/hora = R$ 800/mês
- 5 horas/mês de retrabalho por erro de sincronização × R$ 80/hora = R$ 400/mês
- 2 horas/mês de suporte técnico para “consertar” dados desencontrados × R$ 120/hora = R$ 240/mês
- Total por cliente: R$ 1.440/mês
Custo total para 200 clientes: R$ 288.000/mês. Ou R$ 3,4 milhões/ano.
Mas isso é só o custo direto. O custo indireto é pior:
- Churn antecipado: Se 5% dos clientes cancelam 6 meses antes do previsto por “baixa adoção” (10 clientes × R$ 180.000 LTV) = R$ 1,8M perdidos/ano.
- Expansão bloqueada: Clientes com Shadow IT não compram módulos adicionais (estimativa conservadora: 20% dos clientes × R$ 50.000 de upsell perdido) = R$ 2M/ano em receita não realizada.
- Custo de aquisição desperdiçado: Para repor os 10 clientes que cancelaram, você gasta CAC de R$ 45.000 × 10 = R$ 450.000/ano.
Custo total estimado do Shadow IT: R$ 7,7 milhões/ano.
E esse número não aparece em lugar nenhum no balanço. Não aparece como “custo de Shadow IT”. Aparece diluído em “custo de suporte”, “churn”, “receita não realizada”. Mas a causa raiz é uma só: fricção de produto.
O diagnóstico: 5 perguntas para descobrir se seu sistema está gerando Shadow IT
Você não precisa de uma auditoria de segurança para detectar Shadow IT. Precisa de uma auditoria de fricção. Aqui estão as perguntas que a KARIO faz em todo diagnóstico:
1. “Existe alguma tarefa que o usuário faz fora do sistema porque dentro é difícil demais?”
Se a resposta for sim, você tem fricção de fluxo. O caminho dentro do produto é mais longo, mais confuso ou mais lento do que o caminho improvisado.
Como descobrir: Entrevistas com 5-10 usuários operacionais. Pergunta direta: “Me mostra como você faz a tarefa X”. Se a resposta envolver abrir outro programa, anotar em papel, ou fazer conta de cabeça, você achou um workaround.
2. “O usuário consegue ver o resultado do próprio trabalho dentro do sistema?”
Se ele precisa exportar dados para Excel para gerar um relatório, o sistema está falhando em devolver valor. Ele coleta, mas não mostra.
Como descobrir: Analise as exportações de dados dos últimos 3 meses. Quais relatórios são mais exportados? Por quê? O que o usuário faz com esses dados depois?
3. “Quantos tickets de suporte são sobre ‘como fazer X’ — onde X é uma tarefa que deveria ser óbvia?”
Se o usuário precisa de ajuda humana para completar uma tarefa básica, o produto falhou. E quando o suporte demora ou não resolve, ele improvisa.
Como descobrir: Categorize os últimos 500 tickets. Quantos são “como fazer X”? Quantos são “não consigo encontrar Y”? Quantos são “o sistema não me deixa fazer Z”?
4. “Existem integrações que o cliente precisa, mas que não existem oficialmente no produto?”
Se o cliente conecta seu sistema a outras ferramentas por conta própria, ele está compensando uma lacuna de produto com criatividade. E criatividade do usuário não escala.
Como descobrir: Pergunte ao CS: “Quais ferramentas os clientes mais pedem para integrar?”. Depois pergunte: “Quantas dessas integrações existem?”. A diferença é o seu backlog de Shadow IT.
5. “O fluxo do sistema corresponde ao fluxo real de trabalho do usuário?”
Essa é a pergunta mais importante. Se o sistema foi desenhado para a arquitetura de dados, mas o usuário pensa em termos de tarefas operacionais, haverá mismatch. E mismatch gera workaround.
Como descobrir: Shadowing. Acompanhe 3-5 usuários por 1 hora. Anote cada vez que eles “saem” do fluxo esperado do sistema. Cada desvio é um ponto de fricção.
A solução não é proibir. É eliminar a causa.
Aqui está o erro que a maioria das empresas comete ao descobrir Shadow IT: proibir. Bloquear o Excel. Restringir acesso. Punir quem usa ferramentas não autorizadas.
Isso não resolve. Piora. Porque o usuário não vai parar de precisar fazer o trabalho. Ele vai encontrar outro workaround. E a relação com o sistema vai deteriorar mais.
A solução é eliminar a causa da fricção que gerou o workaround. Se a planilha existe porque o sistema não gera relatórios, construa os relatórios. Se o fluxo paralelo existe porque o caminho oficial tem 12 passos, simplifique para 4. Se a gambiarra de integração existe porque não há API, crie a API.
E aqui entra o princípio fundamental da KARIO: evolução sem interrupção. Você não precisa parar o sistema. Não precisa reescrever tudo. Precisa identificar os pontos de maior fricção — aqueles que estão gerando os workarounds mais críticos — e corrigi-los de forma cirúrgica, integrando o novo ao legado sem quebrar a operação.
O framework é simples e já validado em dezenas de sistemas:
Passo 1: Mapear os workarounds existentes
Entrevistas com usuários operacionais. Análise de tickets. Observação de fluxo (shadowing). O objetivo é criar um inventário de fricção — uma lista de todos os workarounds identificados, categorizados por tipo (compensação, execução, integração).
Passo 2: Priorizar pelo impacto
Nem todo workaround tem o mesmo impacto. Use esta matriz:
| Critério | Peso | Como medir |
|---|---|---|
| Número de usuários afetados | Alto | Quantos usuários usam o workaround? |
| Tempo perdido por usuário | Alto | Quantas horas/mês cada usuário gasta? |
| Risco de erro | Médio | Qual a probabilidade de erro no workaround? |
| Impacto no churn | Alto | O workaround está em contas com risco de cancelamento? |
A interseção de alto impacto em todos os critérios é onde você começa.
Passo 3: Corrigir no produto
Simplificar fluxo. Adicionar funcionalidade. Criar integração. O importante é que a correção torne o caminho oficial mais fácil do que o workaround. Não é sobre proibir. É sobre tornar o produto o caminho de menor resistência.
Passo 4: Medir antes e depois
O workaround sumiu? O uso do sistema aumentou? Os tickets caíram? Sem medição, qualquer melhoria é anedótica. Com medição, ela se torna argumento comercial.
Passo 5: Sustentar
Monitorar para que novos workarounds não surjam. Implementar processos de Design Ops para que o time interno não volte a gerar fricção. Treinar o time para reconhecer sinais precoces de Shadow IT.
O que acontece quando você elimina a fricção
Quando o sistema se torna o caminho de menor resistência — quando é mais fácil usar o produto do que improvisar fora dele — algo mágico acontece. O Shadow IT desaparece naturalmente. Não por proibição. Por irrelevância.
E com ele desaparecem os sintomas:
- O suporte para de receber tickets de “como fazer X”.
- A equipe para de duplicar trabalho.
- O uso real do sistema sobe.
- A percepção de valor sobe.
- A renovação de contrato deixa de ser uma batalha.
- O cliente expande (compra mais módulos, faz upgrade).
Isso é o que a KARIO chama de transformar o sistema de motivo de perda de cliente em vantagem competitiva. Não com redesign genérico. Não com “modernização de interface”. Com diagnóstico preciso, intervenção cirúrgica e medição de resultado.
Porque no final do dia, a pergunta que o seu cliente faz na hora de renovar não é “o sistema é bonito?”. É: “Minha equipe usa isso de verdade? Isso nos ajuda a ganhar dinheiro?”
Se a resposta for “eles usam uma planilha por fora”, você já perdeu. Só não percebeu ainda.
O ciclo vicioso do Shadow IT (e como quebrá-lo)
Shadow IT não é um evento isolado. É um ciclo que se auto-reforça:
Fricção no produto → Usuário cria workaround → Workaround funciona → Usuário para de usar o sistema → Uso real cai → Produto não recebe feedback → Produto não melhora → Mais fricção → Mais workarounds → Mais abandono → Churn.
E o ciclo se acelera porque cada workaround que “funciona” valida a decisão do usuário de não usar o sistema. E quanto mais usuários usam workarounds, menos dados o produto tem sobre como os usuários realmente trabalham. E sem dados, o produto não pode melhorar.
Para quebrar o ciclo, você precisa intervir em um ponto específico: tornar o produto mais fácil do que o workaround. Não em todas as tarefas. Nas tarefas críticas. Nas tarefas que geram mais fricção, mais tempo perdido, mais risco de erro.
E isso exige diagnóstico. Exige dados. Exige método.
O próximo passo
Se você reconheceu o Shadow IT na sua base de clientes — se já ouviu “a equipe tem um jeitinho” ou “eles fazem por fora porque o sistema não deixa” — o próximo passo não é culpar o usuário. Não é proibir a planilha. Não é comprar uma ferramenta de segurança.
O próximo passo é diagnosticar a fricção que está gerando o workaround.
Na KARIO, fazemos exatamente isso. Entramos no sistema que já está em operação. Mapeamos onde os usuários estão improvisando. Identificamos a fricção raiz. E evoluímos o produto junto com o seu time, sem parar a operação, até que o sistema se torne o caminho mais fácil — não o mais obrigatório.
O Diagnóstico de Shadow IT da KARIO entrega:
- Inventário completo de workarounds — categorizados por tipo, impacto e custo.
- Mapa de fricção raiz — onde o produto está falhando em atender ao fluxo real de trabalho.
- Roadmap de intervenção — o que corrigir primeiro, com maior impacto e menor risco.
- Projeção de ROI — quanto cada intervenção vai economizar em suporte, churn e produtividade.
Sem compromisso de execução. Sem proposta genérica. Um diagnóstico honesto que diz exatamente onde está o Shadow IT, quanto ele custa e o que fazer a respeito.
E se o diagnóstico revelar que parte do problema não é fricção — que é falta de funcionalidade, que é integração impossível, que é limitação técnica — nós dizemos isso também. Porque transparência é inegociável.
Fale com a KARIO e descubra onde o seu produto está gerando Shadow IT.
Perguntas frequentes
O que é Shadow IT no contexto de SaaS B2B?
Shadow IT é qualquer ferramenta, processo ou solução que o usuário cria ou adota fora do sistema oficial para realizar o trabalho. Inclui planilhas paralelas, grupos de mensagem para coordenação, scripts de automação improvisados e conexões não autorizadas com outras ferramentas.
Shadow IT é sempre um problema de segurança?
Não. Embora existam riscos de segurança, a causa raiz do Shadow IT em sistemas de gestão é quase sempre fricção de produto: fluxos complexos demais, falta de funcionalidade, ausência de integrações ou interfaces que não correspondem ao fluxo real de trabalho do usuário.
Como saber se meu sistema está gerando Shadow IT?
Procure por sinais: usuários que exportam dados para Excel, equipes que coordenam por WhatsApp em vez de usar o sistema, processos que “funcionam diferente” do que o sistema prevê, tickets recorrentes sobre as mesmas tarefas. Entrevistas com usuários operacionais são a forma mais rápida de descobrir.
Proibir a planilha resolve o problema?
Não. Proibir o workaround sem eliminar a causa apenas força o usuário a encontrar outro caminho paralelo. A solução é identificar a fricção que gerou o workaround e corrigi-la no produto, tornando o sistema o caminho de menor resistência.
Qual a relação entre Shadow IT e churn?
Shadow IT é um indicador direto de baixa adoção. Quando o usuário substitui partes do sistema por soluções próprias, o uso real cai. Na hora da renovação, o decisor percebe que o sistema não é usado de verdade e cancela. Segundo a Gainsight, 67% do churn em SaaS está correlacionado com baixa adoção.
Quanto tempo leva para eliminar Shadow IT?
Depende da profundidade. Quick wins (adicionar um relatório que estava sendo feito no Excel, simplificar um fluxo de 12 passos para 4) podem gerar impacto em 2-4 semanas. Mudanças estruturais (criar integrações, redesenhar fluxos complexos) levam de 2 a 4 meses. O importante é começar pelo diagnóstico e priorizar pelo impacto.
Preciso reescrever o sistema para resolver Shadow IT?
Não. Na maioria dos casos, a abordagem mais eficaz é a evolução incremental: identificar os pontos de maior fricção, corrigir um a um, integrar o novo ao legado sem interromper a operação. Rebuilds completos são caros, arriscados e raramente necessários.
Referências e Fontes
Este artigo foi construído com base em pesquisa acadêmica, dados de mercado e frameworks de ciência cognitiva aplicados a produtos digitais B2B.
Shadow IT e Comportamento Organizacional
- Gartner: Dados sobre prevalência de Shadow IT em organizações (mais de 80% das empresas convivem com algum grau) e riscos associados. Link
- A Systematic Literature Review on Trust in the Software Ecosystem: Estudos sobre comportamentos disfuncionais (planilhas paralelas, sabotagem silenciosa) como resposta à baixa confiança no sistema. Springer
- Reuters / CXL: Dados sobre sobrecarga de informação, paralisia analítica (43% de decisões atrasadas) e tensão entre colegas (66%). Link
Ciência Cognitiva e Carga Cognitiva
- Teoria da Carga Cognitiva (John Sweller): Fundamentos sobre capacidade limitada da memória de trabalho e os três tipos de carga (intrínseca, extrínseca, germânica). PMC/NIH
- Steve Krug: “Don’t Make Me Think” — princípio de minimização de carga cognitiva extrínseca.
- The Decision Lab: Referência sobre Sistema 1 e Sistema 2 (Dual Process Theory de Kahneman). Link
- Nir Eyal: Aplicação da Dual Process Theory ao design de produtos e formação de hábitos.
Churn, Adoção e Retenção em SaaS
- Gainsight / Kissmetrics: 67% do churn em SaaS correlacionado com baixa adoção do produto. Link
- Harvard Business Review / CEB: Dados sobre Customer Effort Score e a correlação entre baixo esforço e lealdade. Link
Posicionamento KARIO
- Sobre a KARIO: Diagnóstico de fricção em sistemas de gestão e SaaS em operação. Evolução sem interrupção. kario.com.br
Este artigo foi escrito pela equipe da KARIO, parceira estratégica de produto e tecnologia especializada em sistemas de gestão e SaaS em operação. Diagnosticamos onde o sistema perde valor. Evoluímos a solução junto com o seu time, sem interromper a operação. O resultado: menos churn, menos carga no suporte, e um sistema que vira vantagem competitiva.