Comprar sistema é uma das decisões mais fáceis de defender numa empresa. Tem escopo, prazo, fornecedor, orçamento e um comitê disposto a aprovar. E, na maior parte dos casos, é acerto: a operação cresceu, a planilha não dá mais conta, o dado precisa estar em algum lugar.

A leitura corrente é que o risco está na execução do projeto: atraso, estouro de escopo, resistência do usuário. Talvez. Mas a parte que custa dinheiro não é o projeto que dá errado. É o projeto que dá certo: entra no ar no prazo, é adotado, aparece nos indicadores de uso, e a empresa continua decidindo exatamente como decidia antes.

Um sistema novo torna a operação mais visível. Não necessariamente melhor. Quando o processo permanece o mesmo, o que muda é o formato do registro: o improviso deixa de estar na planilha e passa a estar na tela.

O que a medição já mostra

A evidência mais direta sobre isso vem de um painel de mais de onze mil estabelecimentos britânicos, cruzando dados oficiais do censo econômico com gastos de tecnologia. Nicholas Bloom, Raffaella Sadun e John Van Reenen mediram o retorno de dobrar o estoque de capital de TI e encontraram dois números completamente diferentes para a mesma coisa.

Retorno de dobrar o capital de TI, por modelo de gestão

  • Estabelecimentos de multinacionais americanas: +4,9% de produtividade
  • Demais estabelecimentos: +1,2%

Mesmo capital de TI, quatro vezes o retorno. E o ponto decisivo: quando se controla pelas práticas de gestão de pessoas, a vantagem americana desaparece estatisticamente. Não era a tecnologia, era o modelo que a recebia. Fonte: Bloom, Sadun e Van Reenen, American Economic Review, 2012; painel de mais de 11 mil estabelecimentos do Reino Unido, 1995 a 2003. A identificação vem de aquisições: a diferença só aparece dois anos depois da troca de dono, não antes.

Esse desenho com aquisições é o que torna o achado difícil de descartar. Antes da compra, os estabelecimentos que viriam a ser adquiridos por americanos não se distinguiam dos demais. Depois, com o mesmo parque tecnológico e outro modelo de gestão, o retorno da tecnologia mudou.

Há um segundo achado, e ele separa duas coisas que a empresa costuma tratar como uma só. Aral, Brynjolfsson e Wu acompanharam 623 grandes empresas americanas entre 1998 e 2005 e distinguiram o evento de compra do sistema do evento de entrada em uso. Para ERP, os eventos de compra não apresentaram correlação com desempenho. Os eventos de go-live, sim.

Assinar contrato não é o mesmo que operar diferente, e só a segunda coisa aparece no resultado.

Onde isso começa

  • Planilhas paralelas convivendo com o sistema oficial.
  • Campos preenchidos por obrigação, sem uso gerencial.
  • Dashboards que ninguém usa para decidir.
  • Usuários contornando o sistema para conseguir trabalhar.
  • Integrações técnicas sem integração operacional entre as áreas.
  • Dados divergentes entre áreas na mesma reunião.

Cada um desses sinais aponta para a mesma origem: a informação não tem dono, e por isso não tem confiabilidade. Enquanto não houver definição única, responsável e momento de atualização, cada área continua produzindo a sua própria versão do mesmo número, e o sistema, que não arbitra, guarda todas elas. O dano atravessa três estágios, e a maior parte dos comitês de projeto só enxerga o último.

Como o dano avança

Estágio 1, invisível: dado sem dono, campo sem uso gerencial, usuário contornando o sistema, planilha paralela, integração técnica sem integração operacional.

Estágio 2, estrutural: processo, dono do dado, critério e rotina de decisão.

Estágio 3, mensurável: decisão por percepção, números divergentes na mesma reunião, conhecimento que sai com a pessoa, retrabalho de reimplantação, licença sem contrapartida.

Entre o estágio 1 e o estágio 3 costuma passar um ciclo inteiro de contrato. E o gatilho que revela o estágio 3 quase sempre é a proposta de trocar o sistema, que é a decisão mais cara possível quando o problema não estava no sistema.

Digitalizar um processo indefinido não o organiza. Só torna a indefinição mais rápida.

Por que isso não dá sinal

O projeto de tecnologia tem métrica própria, e ela não mede a coisa que importa. Prazo, orçamento, escopo entregue, usuários treinados, percentual de uso: tudo isso pode estar verde enquanto nenhuma decisão passou a ser tomada de outro jeito. O critério de sucesso mede a entrega da infraestrutura, não a mudança da operação, e ninguém é cobrado por uma variável que não está no contrato.

Há uma segunda razão, e ela é de ordem de discussão. Quando a conversa começa pela funcionalidade, a empresa passa a adaptar a operação ao que a ferramenta oferece. Quando começa pela decisão que alguém precisa tomar, a ferramenta é configurada para sustentá-la. Isso não significa recusar as boas práticas embutidas no produto: significa saber qual decisão cada campo, cada etapa e cada automação deve sustentar. Um campo que não sustenta decisão nenhuma é custo de digitação disfarçado de governança.

E há uma terceira, que explica por que a adoção some depois de alguns meses. Treinamento e cobrança sustentam o uso por algumas semanas. O que sustenta no longo prazo é utilidade: o sistema devolve a quem preenche alguma coisa que ajuda a trabalhar, e é a fonte que a liderança usa para decidir. Quando a reunião de gestão continua acontecendo fora da ferramenta, o time entende a mensagem real, o registro é burocracia e não parte do trabalho. E age de acordo.

Onde o custo aparece

O custo mais caro é o de inverter a ordem do diagnóstico: concluir que o sistema é ruim e trocá-lo. É a decisão mais cara possível quando o problema não estava nele, e ela recomeça o ciclo com a mesma indefinição.

O segundo custo é a planilha paralela, que raramente é tratada como risco. A melhor compilação de auditorias de planilhas operacionais reais, cinco estudos independentes e 55 planilhas em uso, encontrou erros sérios em 91% delas. É uma base pequena e antiga, e vale dizer isso; mas é a única que existe, e a direção nunca foi contestada. Toda decisão que migra do sistema oficial para uma planilha de apoio migra também para fora de qualquer controle.

O terceiro custo é de sequência, e há um experimento que o ilustra ao contrário. No estudo aleatorizado de Bloom e colegas em 28 plantas têxteis indianas, quatro meses de introdução de práticas básicas de gestão elevaram a produtividade em 11,1% e reduziram defeitos em 32%.

O que mudou quando a gestão mudou primeiro

  • Produtividade: +11,1%
  • Defeitos de qualidade: −32%
  • Estoque de matéria-prima: −16,4%

Nenhuma das práticas introduzidas era um software. E o dado que fecha o argumento está numa nota do estudo: as horas semanais de uso de computador aproximadamente dobraram nas plantas tratadas. A informatização foi consequência da mudança de gestão, não causa dela. Fonte: Bloom, Eifert, Mahajan, McKenzie e Roberts, Quarterly Journal of Economics, 2013; 28 plantas em 17 empresas, um setor, um país. Efeito grande, amostra pequena.

No Grupo Technos, o trabalho seguiu essa lógica: processo desenhado, requisitos definidos a partir dele, dados estruturados com dono e critério, e só então a tecnologia configurada para sustentar a rotina de gestão e a decisão comercial. É observação de campo, não medição: não temos antes e depois auditado, e registrar isso faz parte do método.

Onde essa tese tem limite

A evidência mostra acoplamento, e eu escrevi sequência. Esta é a objeção mais séria, e ela é correta. Toda a literatura citada aqui estabelece que tecnologia e organização são complementos: uma aumenta o retorno da outra, nos dois sentidos. Complementaridade é simétrica; não diz que a organização precisa vir primeiro. Aral, Brynjolfsson e Wu chamam o fenômeno de ciclo virtuoso, que é um laço de retroalimentação e não uma fila. A afirmação que sobrevive não é "processo antes de tecnologia". É esta: a tecnologia não decide o que a empresa quer, quem responde pelo número e o que acontece quando o número está errado. Isso ela não faz sozinha, em nenhuma ordem.

Às vezes a ferramenta produz o processo. Em experimento com 5.179 atendentes publicado no Quarterly Journal of Economics, o acesso à ferramenta, sem redesenho prévio de processo, elevou a produtividade em 14%, e em 34% entre os novatos, com evidência de que o sistema extraiu as práticas dos operadores mais capazes e as distribuiu para os demais. Ninguém escreveu o processo antes: a ferramenta o produziu. Orlikowski e Hofman já haviam argumentado, em 1997, que para tecnologias abertas a mudança útil é emergente, não desenhada de antemão. "Requisito vem do processo" precisa admitir a versão fraca: o requisito vem de uma decisão que alguém precisa tomar, e essa decisão às vezes é descoberta pelo uso.

Maturidade de processo explica menos do que a tese sugere. Isso também foi testado. Maturidade de gestão de processos em 120 organizações alemãs e holandesas explica cerca de 10% da variância de desempenho organizacional, e a relação positiva só existe até os primeiros níveis; entre maturidade alta e desempenho, nada. E na maior pesquisa sobre requisitos que existe, com 228 empresas em dez países, "requisitos incompletos" é o problema mais citado e um dos que menos se converte em fracasso; o que mais converte é falha de comunicação entre time e cliente. O gargalo é conversa, não especificação, o que enfraquece a leitura de que basta documentar melhor.

Os números do gênero são ruins, e eu vendo o remédio. "70% das transformações digitais falham" remonta a uma estimativa que os próprios autores chamaram de não científica em 1993. O custo médio de US$ 12,9 milhões por má qualidade de dados não tem população, ano nem método publicados. A Standish nunca divulgou sua amostragem. O "95% dos projetos de IA falham" é um relatório de uma empresa de infraestrutura de IA com 153 respondentes autosselecionados. Nenhum deles está neste artigo, e a tese precisa sobreviver sem eles: se não sobreviver, é posicionamento comercial, não tese. Declaro o restante: presto serviço de estruturação de processo e gestão, e o argumento aqui coincide com o escopo do que vendo. Por isso toda afirmação central está apoiada em fonte externa nomeada, com amostra e período declarados, inclusive as que me contrariam.

Como transformar isso em rotina

Quatro definições antes de configurar, e uma quinta que decide se o projeto valeu. Nenhuma delas é técnica.

A decisão, não a tela. Para cada módulo, escreva qual decisão ele precisa sustentar e quem a toma. Dono: quem responde pela área. Gatilho: antes de qualquer especificação. O teste é direto: se ninguém consegue nomear a decisão, o campo não deveria existir.

Dono do dado. Cada informação crítica tem um responsável nomeado, definição única e momento de atualização declarado. Dono: quem usa o número para decidir, não quem o digita. Gatilho: qualquer divergência entre áreas, que é sintoma de definição, não de sistema.

A planilha paralela como diagnóstico. Liste o que hoje é feito fora do sistema e por qual motivo. Dono: quem lidera o projeto. Gatilho: antes de comprar, e de novo seis meses depois de entrar no ar. Cada planilha é um requisito que ninguém coletou ou uma decisão que a ferramenta não sustenta.

A rotina que usa o dado. Defina qual reunião vai usar aquela informação, com que frequência e para decidir o quê. Dono: quem preside. Gatilho: antes do go-live. Enquanto a reunião de gestão acontecer fora da ferramenta, a adoção será sempre uma cobrança, nunca um hábito.

O critério de sucesso observável. Escreva, antes de começar, como saberemos em três meses que a forma de trabalhar mudou. Dono: o patrocinador do projeto. Gatilho: aprovação do investimento. Entrar no ar e atingir percentual de uso não são critérios de sucesso, são pré-requisitos.

Nenhuma dessas cinco definições melhora o cronograma do projeto. Todas melhoram a probabilidade de que, um ano depois do go-live, alguém consiga apontar uma decisão que passou a acontecer de outro jeito.

E vale ser preciso sobre o que a evidência sustenta, para fechar. Tecnologia é indispensável em qualquer operação que pretenda crescer com consistência, e um bom sistema sobre um processo claro acelera a gestão de verdade: o retorno de 4,9% é real, não retórica. O que a medição mostra é que esse mesmo sistema, sobre um modelo indefinido, rende 1,2%. A ferramenta é uma função de transferência: ela devolve, amplificado, o modelo que recebe.

O sistema entrou no ar. O que passou a ser decidido de outro jeito?

Fontes

  1. 01Bloom, Sadun e Van Reenen. Americans Do I.T. Better: US Multinationals and the Productivity Miracle, American Economic Review, 2012. Painel de mais de 11 mil estabelecimentos do Reino Unido, 1995 a 2003, com dados do censo econômico casados a gastos de TI; dobrar o capital de TI eleva a produtividade em 4,9% nos estabelecimentos de multinacionais americanas contra 1,2% nos demais, e a diferença desaparece ao controlar por práticas de gestão de pessoas. Identificação por aquisições. worldmanagementsurvey.org
  2. 02Aral, Brynjolfsson e Wu. Which Came First, IT or Productivity? The Virtuous Cycle of Investment and Use in Enterprise Systems, 2006. 623 grandes empresas americanas, 1998 a 2005; para ERP, eventos de compra não correlacionam com desempenho e eventos de entrada em uso correlacionam. Os autores descrevem o fenômeno como ciclo virtuoso, não como sequência. ssrn.com
  3. 03Bloom, Eifert, Mahajan, McKenzie e Roberts. Does Management Matter? Evidence from India, Quarterly Journal of Economics, 2013. Experimento aleatorizado em 28 plantas de 17 empresas têxteis; +11,1% de produtividade, −32% de defeitos, −16,4% de estoque; as horas de uso de computador aproximadamente dobraram nas plantas tratadas. worldmanagementsurvey.org
  4. 04Brynjolfsson, Hitt e Yang. Intangible Assets: Computers and Organizational Capital, Brookings Papers on Economic Activity, 2002. Painel de 1.216 grandes empresas americanas, 1987 a 1997; cada dólar de capital computacional associado a cerca de doze dólares de valor de mercado, contra 1,18 a 1,47 para planta e equipamento. No subconjunto com dados organizacionais, o coeficiente cai de 14,6 para 5,4 ao incluir a interação entre computador e práticas organizacionais. brookings.edu
  5. 05Brynjolfsson, Li e Raymond. Generative AI at Work, Quarterly Journal of Economics, 2025. 5.179 agentes, rollout escalonado; +14% de produtividade média e +34% entre os novatos, com evidência de que a ferramenta disseminou as práticas dos operadores mais capazes sem redesenho prévio de processo. oup.com
  6. 06Orlikowski e Hofman. An Improvisational Model for Change Management: The Case of Groupware Technologies, MIT Sloan Management Review, 1997. Argumento de que, em tecnologias abertas, a mudança organizacional útil é emergente e improvisacional, e não desenhada integralmente antes da implantação. sloanreview.mit.edu
  7. 07Panko. Spreadsheet Research: What We Know About Spreadsheet Errors, Universidade do Havaí. Compilação de cinco auditorias independentes de 55 planilhas operacionais em uso, com erros sérios em 91% delas. Base pequena, estudos das décadas de 1980 e 1990, com definições de erro que variam entre eles. panko.com
  8. 08Hendricks, Singhal e Stratman. The impact of enterprise systems on corporate performance, Journal of Operations Management, 2007. 186 implantações de ERP, 140 de SCM e 80 de CRM anunciadas entre 1991 e 1999; ganho significativo em SCM, parcial em ERP e nenhuma evidência de melhoria em retorno ou lucratividade em CRM. wiley.com
  9. 09Cetic.br e NIC.br. TIC Empresas 2025. Amostra probabilística de 4.174 empresas brasileiras com dez ou mais pessoas ocupadas, campo de fevereiro de 2025 a janeiro de 2026; 36% usavam ERP e 31% CRM, com forte variação por porte. O indicador mede posse do pacote, não uso gerencial. cetic.br