Acoplados ao jeito como as coisas eram
Sobre organizações rígidas, sistemas fortemente acoplados e por que, numa grande empresa, a mudança precisa começar por dentro.
Trabalhei em um projeto de comércio empresarial para uma grande multinacional. ERP grande, muitos processos internos, muitas pessoas com bastante tempo de casa. E uma mudança numa regra de desconto que, vista pelo código, parecia poucas condições e um teste.
Foi assim que essa mudança percorreu a empresa.
O passeio das aprovações. Uma tirinha, não uma transcrição: as falas são minhas, o percurso é real.
Alinhávamos com a liderança. O Financeiro pedia ajustes. Revisávamos, voltávamos à liderança, recebíamos aprovação e voltávamos ao Financeiro. Então alguém lembrava que outra área precisava ver, e essa área encontrava uma restrição, muitas vezes no ERP, que devolvia a proposta ao início. Mais reuniões, mais retrabalho, a mesma sensação sempre: já passamos por aqui.
O curioso é que ninguém naquele ciclo fazia nada errado. Cada passo fazia sentido isoladamente. O problema era o ciclo, e ele tinha duas metades: uma na organização, outra no software.
A capacidade de mudar é uma competência da empresa
Os mercados mudam. A tecnologia muda e, ultimamente, muda mais rápido que a maioria dos ciclos de planejamento. Uma empresa que vendia por distribuidores decide abrir um canal B2B de comércio eletrônico. Outra, que fazia tudo no ERP, precisa expor preços, estoque e pedidos numa nova frente digital. Nada disso é exótico. É a pressão normal sobre qualquer grande negócio.
O que determina se isso dará certo não é apenas orçamento ou talento. É se a empresa ainda consegue mudar. Passei a pensar nisso como uma competência, como qualquer outra. Você pode tê-la, pode perdê-la e geralmente só percebe a perda quando precisa dela.
Na minha experiência, grandes empresas a perdem em dois lugares ao mesmo tempo.
Como um sistema fica engessado
O primeiro lugar é a arquitetura.
Pense em digitalizar uma operação centrada no ERP para vender B2B online. Num sistema saudável, isso é um novo canal: ele conversa com preços, clientes, estoque e pedidos por contratos, e essas capacidades conversam com o ERP por uma integração.
Num sistema rígido, essas capacidades não estão separadas. Ao longo dos anos, funções que deveriam viver à parte, em serviços ou ao menos módulos próprios, foram empilhadas. A lógica de descontos conhece as regras de crédito do cliente. As regras de crédito leem diretamente tabelas do ERP. O checkout pressupõe um fluxo de pedidos específico, que pressupõe uma rotina de estoque específica. Cada camada se apoia na de baixo.
Ninguém projeta isso de propósito. Acumula-se, um atalho razoável de cada vez, até as camadas não poderem mais ser separadas. Então uma mudança que deveria tocar uma coisa toca seis.
Esse é o custo arquitetural da rigidez e a razão de eu insistir em baixo acoplamento. Não porque caixas separadas ficam mais bonitas num diagrama, mas porque o acoplamento determina quanto do sistema uma decisão de negócio arrasta consigo. Uma regra de desconto deveria ser uma decisão de preços. Se mudá-la exige negociar com o fluxo de pedidos, a rotina de estoque e as entranhas do ERP, a arquitetura transformou uma decisão comercial numa escavação.
Baixo acoplamento também tem custo, e não vou fingir que não. Contratos precisam ser projetados e mantidos. Integrações precisam de responsáveis. Algumas coisas são duplicadas de propósito. É mais lento no primeiro dia. Compensa quando o mercado pede algo que o projeto original nunca imaginou e, na minha experiência, esse dia sempre chega.
A outra metade do ciclo
O segundo lugar em que a empresa perde a capacidade de mudar é nas pessoas.
Numa grande empresa, muita gente passou anos, às vezes décadas, trabalhando com as mesmas regras, sistemas e caminhos de aprovação. Essa experiência é real e valiosa. Também pesa.
O que vi repetidamente foi resistência a mudar a forma de trabalhar. Propostas que pareciam resolvidas voltavam para mais uma discussão. Às vezes parecia que o projeto sofria um boicote silencioso.
Não acho que a maior parte fosse deliberada. Minha leitura honesta é que muitas vezes era inconsciente: pessoas protegendo a forma de trabalhar que conheciam, a que sempre funcionou para elas. Basicamente, inércia.
É fácil se frustrar com isso. É mais útil entender. Um sistema rígido e uma organização rígida se alimentam. Quando o software não pode mudar sem grande risco, as pessoas aprendem a dizer não à mudança, muitas vezes com razão. Quando dizem não por muito tempo, ninguém investe em facilitar mudanças no software. O gesso engrossa dos dois lados.
Forçar de fora não funciona
A reação natural ao chegar como parte de uma equipe externa é pressionar. Você tem a missão, o plano e o apoio da liderança. Às vezes a liderança pode simplesmente decidir, e isso move as coisas. Mas pressionar de fora tem um efeito previsível: as pessoas passam a rejeitar o próprio projeto. Quanto mais você força, mais a organização trata a mudança como algo imposto a ela. Na minha experiência, é uma das formas mais garantidas de um projeto não avançar.
Vale pensar no motivo. Uma mudança imposta de fora pede às pessoas que abandonem o que conhecem em troca de algo que não ajudaram a construir, proposto por quem não sabe como a empresa realmente funciona. Colocada assim, a resistência faz sentido.
O que funcionou: mudar de dentro para fora
O que fez diferença naquele projeto foi encontrar pessoas dentro da empresa dispostas a mudar e aproximá-las do trabalho.
Quero ser específico, porque é fácil interpretar errado: não eram necessariamente as pessoas mais novas. Algumas das mais importantes estavam lá havia muitos anos. Conheciam os fluxos internos, quem decidia o quê, quais precedentes existiam e por que uma proposta passaria ou não. A diferença não era idade nem tempo de casa. Era disposição. Estavam abertas a fazer diferente e conheciam a empresa o suficiente para tornar isso possível.
Procuramos essas pessoas, conquistamos sua confiança e demos a elas um papel real no trabalho. Elas explicavam por que algo não passaria como havíamos escrito e o que passaria. Diziam quem precisava estar numa conversa antes de ela acontecer, não depois. Lembravam que algo parecido já havia sido aprovado: uma espécie de jurisprudência interna, sem os advogados. Com seu apoio, conseguimos avançar em mudanças mais significativas e inovar dentro de uma estrutura que resistia.
Não foi uma vitória limpa. Algumas propostas foram adiadas ou descartadas. Em alguns pontos aceitamos soluções que sabíamos que poderiam encontrar limites depois, tentando construí-las para que evoluíssem. Uma escolha pragmática ainda tem custo real, e deixar espaço para mudá-la depois não torna a mudança gratuita. Só a torna possível.
Também precisei aprender algo menos confortável: eu precisava daquelas pessoas mais do que elas precisavam de mim. Eu respondia pela parte técnica, mas não entendia a empresa. Elas entendiam.
O que levo disso
Duas coisas, que são a mesma lição vista por dois lados.
No software: proteja o baixo acoplamento. Separe capacidades de negócio, coloque contratos entre elas e não deixe o ERP, ou qualquer sistema único, virar o lugar onde todas as regras moram. O objetivo não é elegância. É manter a empresa capaz de responder à próxima mudança de mercado, ao próximo canal, à próxima tecnologia, sem escavar.
Na organização: não tente impor a mudança de fora. Encontre as pessoas de dentro que conhecem os fluxos e querem avançar, apoie-as e construa a mudança com elas. É mais lento no começo. É a única versão que vi realmente permanecer.
Um sistema que não muda e uma empresa que não muda costumam vir juntos. É preciso trabalhar nos dois, e o segundo começa pelas pessoas.