Lei de Conway: por que o sistema da sua empresa tem a cara do organograma
Todo diretor de TI já ouviu alguma versão desta reclamação: “o cliente está cadastrado de um jeito no comercial, de outro no financeiro e de um terceiro na expedição”. A primeira reação é culpar o sistema. Mas, olhando com calma, o sistema só está repetindo, com bastante fidelidade, a forma como essas três áreas sempre trabalharam: cada uma com seu cadastro, seu horário e seu jeito de conversar com as outras.
Esse fenômeno é tão comum que tem nome há quase 60 anos: Lei de Conway. Entendê-la ajuda a explicar por que tantos sistemas legados ficaram do jeito que estão e, principalmente, por que trocar de sistema nem sempre resolve.
O que diz a Lei de Conway?
Em abril de 1968, o programador Melvin Conway publicou na revista Datamation o artigo “How Do Committees Invent?”. A ideia central, nas palavras do próprio autor em uma nota posterior, é que qualquer organização que desenha um sistema vai produzir um desenho cuja estrutura é uma cópia da estrutura de comunicação dessa organização.
Em linguagem de gestão: se duas áreas não conversam, os sistemas delas também não vão conversar. Se uma decisão depende de três aprovações em três departamentos, o software vai ter três telas, três cadastros e, quase sempre, uma planilha fazendo a ponte entre eles.
A observação ganhou o nome de Lei de Conway alguns anos depois, quando Fred Brooks a citou no livro The Mythical Man-Month, um clássico da gestão de projetos de software. Desde então, ela é uma das explicações mais usadas para entender por que sistemas crescem com a forma que crescem.
Como reconhecer o organograma dentro do sistema?
Na maioria das empresas com sistemas antigos, a Lei de Conway aparece em sinais bem concretos do dia a dia:
O mesmo dado em vários lugares. Cliente, produto ou fornecedor cadastrados em mais de um módulo, com códigos diferentes, porque cada área montou o seu quando precisou.
A planilha que faz a ponte. Toda segunda-feira alguém exporta um relatório de um sistema, ajusta à mão e importa em outro. Essa planilha marca exatamente o ponto em que duas equipes nunca combinaram um processo comum.
A integração que espelha uma reunião. Um arquivo que sai do sistema da produção às 18h e entra no sistema do faturamento às 7h do dia seguinte existe porque, um dia, as duas áreas combinaram trocar informação uma vez por dia. A rotina continua, mesmo que hoje o negócio precise da informação na hora.
O módulo sem dono. Partes do sistema que foram construídas por um time que já não existe, ou por uma área que mudou de nome, viram ilhas. Ninguém mexe porque ninguém sabe quem é o dono, o mesmo risco do fator ônibus.
Nenhum desses sinais é um erro técnico isolado. Cada um é uma marca de como a empresa estava organizada quando aquela parte do sistema foi construída.
Por que trocar o sistema não resolve sozinho?
Aqui está a parte que mais interessa a quem decide investimento. Se o sistema é uma cópia da comunicação entre as áreas, um sistema novo, desenhado pelas mesmas áreas, com as mesmas fronteiras e as mesmas reuniões, tende a reproduzir os mesmos problemas, agora com tecnologia mais moderna.
É comum ver uma empresa trocar o ERP, gastar meses de projeto e, ao final, descobrir que a planilha de segunda-feira continua lá. O motivo é simples: no levantamento de requisitos, cada área pediu o que já fazia, do jeito que já fazia. Ninguém tinha mandato para redesenhar o processo de ponta a ponta, então o sistema novo herdou as fronteiras do antigo.
Isso não significa que modernizar é inútil. Significa que a modernização precisa olhar para o processo e para quem conversa com quem, e não apenas para a lista de funcionalidades. É também por isso que vale entender as regras escondidas no sistema legado antes de qualquer troca.
O que muda quando a empresa coloca agentes de IA?
A Lei de Conway não vale só para sistemas tradicionais. Ela aparece, com a mesma força, nos projetos de inteligência artificial.
Imagine uma empresa em que o comercial contrata um agente de IA para responder clientes, o financeiro contrata outro para tratar cobranças e o suporte monta um terceiro para chamados. Cada agente consulta a base da sua área, segue as regras da sua área e responde com o vocabulário da sua área. Quando o mesmo cliente pergunta sobre um pedido atrasado e um boleto em aberto, recebe duas respostas que não conversam entre si, exatamente como acontecia antes, quando ele precisava ligar para dois ramais.
Ou seja: a IA também copia o organograma. Se cada departamento cria o seu agente isoladamente, a empresa ganha velocidade em cada ilha, mas mantém as mesmas fronteiras que incomodam o cliente. Por isso, projetos de IA bem-sucedidos costumam começar por um dicionário comum do negócio e por um fluxo pensado a partir da jornada do cliente, e não a partir de cada área.
Como usar a Lei de Conway a favor da empresa?
Se o sistema copia a organização, a pergunta útil passa a ser: qual organização queremos que o sistema copie? Algumas práticas ajudam a responder:
Desenhar o processo antes do sistema. Antes de discutir telas ou fornecedores, mapear o caminho de ponta a ponta, por exemplo do pedido ao recebimento, e marcar em que pontos a informação muda de mãos. Cada mudança de mão é candidata a virar retrabalho no software.
Dar dono ao fluxo, não só ao módulo. Além do responsável por cada área, definir quem responde pelo processo inteiro. Esse dono tem mandato para dizer “aqui não precisamos de dois cadastros”.
Montar o time do projeto com as áreas juntas. Quando comercial, financeiro e operação trabalham no mesmo grupo durante a modernização, o sistema resultante tende a ter menos fronteiras artificiais. A equipe que desenha passa a ter a forma do processo que se quer, e não do organograma que já existe.
Tratar a planilha-ponte como pista. Cada planilha que conecta dois sistemas mostra um acordo entre áreas que nunca virou processo. Ela é um ótimo ponto de partida para priorizar o que integrar ou redesenhar primeiro, inclusive com apoio de IA para ler regras e cálculos que estão nela.
Nada disso exige reescrever tudo de uma vez. A modernização de sistemas legados sem risco funciona melhor quando cada etapa remove uma fronteira desnecessária, em vez de apenas trocar a tecnologia que fica entre as mesmas fronteiras.
Como a RETTA pode ajudar?
A RETTA atua na manutenção e modernização de sistemas legados e na integração desses sistemas com agentes de IA. Começamos mapeando o processo de ponta a ponta e as conversas entre as áreas, identificamos onde o sistema apenas repete fronteiras antigas e propomos uma evolução por etapas, sem parar a operação.
Quer saber quais fronteiras do seu sistema vêm do organograma antigo? Fale com a nossa equipe e descubra o que mudar no processo antes de trocar a tecnologia.