330 produtos em seis meses: o que a LEGO ensina sobre processos modulares

Uma operação consegue oferecer muita variedade sem virar artesanal quando a variação acontece sobre um núcleo reutilizável. O ponto não é tornar todas as entregas iguais. É evitar que cada novo produto, cliente ou projeto obrigue a organização a reinventar componentes, interfaces e decisões que já deveriam estar resolvidos.

Os resultados semestrais divulgados pela LEGO em 25 de agosto de 2026 oferecem um caso interessante. A companhia informou receita recorde de 41,9 bilhões de coroas dinamarquesas no primeiro semestre, alta de 21% sobre o mesmo período de 2025, enquanto as vendas ao consumidor cresceram 22%. No mesmo intervalo, colocou no mercado mais de 330 produtos novos. A Reuters destacou que linhas ligadas à Copa do Mundo, Fórmula 1 e franquias de entretenimento ajudaram a atrair públicos diferentes.

É fácil olhar para esses números apenas como força de marca. Para operações, a pergunta mais interessante é outra: como uma empresa consegue aumentar variedade sem transformar cada lançamento em uma cadeia produtiva inteiramente nova?

A resposta completa da LEGO envolve décadas de engenharia, marca, fornecedores e conhecimento industrial, e não pode ser reduzida à ideia simpática de “blocos que encaixam”. Ainda assim, os dados atuais mostram um princípio operacional útil. A companhia combina um portfólio amplo com investimentos em produtividade, capacidade industrial e tecnologias de manufatura que são desenvolvidas, testadas e escaladas em uma estrutura comum. Em junho, inaugurou em Billund um centro global de inovação de manufatura de 100 mil m², com mais de 1.800 profissionais trabalhando justamente no desenvolvimento, teste e escala de novas tecnologias de produção.

Variedade, portanto, não precisa significar uma operação diferente para cada oferta.

O erro comum é padronizar a experiência inteira

Empresas que querem escalar costumam descobrir o valor da padronização e, em seguida, exagerar. Criam um único fluxo para todos os clientes, um único kickoff, uma única sequência de etapas e o mesmo conjunto de documentos. A operação fica fácil de administrar internamente, mas começa a empurrar diferenças reais para exceções informais.

Um cliente pequeno não tem a mesma governança de uma multinacional. Uma implantação com ERP não tem as mesmas dependências de uma ativação sem integração. Uma automação interna pode aceitar risco diferente de um fluxo que executa uma ação fiscal ou financeira.

A solução não é abandonar padrão. É escolher melhor o que deve ser padrão.

Em produtos modulares, peças comuns criam combinações diferentes. Em processos, o equivalente está nas capacidades reutilizáveis: coletar dados, validar uma condição, conceder acesso, registrar uma decisão, integrar sistemas, pedir aprovação, comunicar uma pendência, testar um resultado e escalar uma exceção. Essas capacidades podem permanecer consistentes mesmo quando a jornada final muda.

É uma diferença importante em relação a simplesmente criar um playbook. O playbook de implantação enterprise diz como uma implantação costuma acontecer. Uma operação modular tenta definir quais partes podem ser reutilizadas em diferentes implantações sem clonar o processo inteiro.

No onboarding, pense em módulos, não em cópias

Imagine uma empresa SaaS com três perfis de cliente.

O primeiro usa o produto de forma praticamente padrão. O segundo precisa integrar o ERP. O terceiro, além da integração, possui requisitos fiscais, segurança corporativa e múltiplas unidades.

Uma operação pouco modular tende a criar três fluxos completos. Depois aparecem variações dentro de cada grupo, e em pouco tempo há oito templates, quatro planilhas e instruções diferentes para atividades que, no fundo, fazem a mesma coisa.

Uma operação mais modular preserva um núcleo comum e adiciona capacidades quando necessárias. A criação de usuários pode ser a mesma. O mecanismo de coleta e validação de acessos pode ser o mesmo. A forma de registrar aceite pode ser a mesma. O que muda é o conjunto de componentes ativados, suas regras e talvez a ordem de algumas dependências.

Isso leva a padronização um passo além. Em vez de perguntar apenas “qual é o processo padrão?”, a pergunta passa a ser “quais partes desse processo são produtos internos reutilizáveis?”.

Essa mudança também melhora automação. É muito mais fácil automatizar um componente estável de validação de acesso usado por vinte fluxos do que manter vinte automações quase iguais, cada uma com pequenas diferenças que ninguém lembra por que existem.

A interface importa mais do que o componente isolado

Modularidade não funciona quando as peças não têm contratos claros entre si.

Um módulo de “validar acesso”, por exemplo, precisa deixar explícito o que recebe, o que considera válido, qual evidência produz, o que acontece quando falha e qual estado libera para a próxima etapa. Sem isso, o componente só parece reutilizável. Na prática, cada equipe continua dependendo de interpretação humana para conectá-lo ao resto do fluxo.

É a mesma lógica observada no artigo sobre a abertura da ferrovia sul-africana a operadores privados: separar partes aumenta autonomia apenas quando as interfaces ficam mais claras. Num processo empresarial, a interface pode ser um status, um evento, um documento validado, uma API ou uma condição de saída.

Esse ponto é especialmente importante para agentes de IA. Um agente que “cuida do onboarding” é uma fronteira ampla demais. Um agente que recebe a evidência de um acesso pendente, identifica o responsável, formula a cobrança com contexto, registra o contato e retorna um estado verificável possui uma interface mais controlável.

Quanto mais claro o contrato entre etapas, mais fácil trocar a implementação. Hoje a ação pode ser manual. Amanhã, uma automação determinística. Depois, um agente. O processo não precisa ser reconstruído porque a capacidade foi definida pelo resultado que entrega, e não pela ferramenta que a executa.

Exceção não deveria criar uma nova versão do processo

Outro sinal de baixa modularidade é quando toda exceção relevante produz um novo fluxo permanente.

Um cliente pede uma aprovação adicional e nasce um template. Outro utiliza uma variante de ERP e ganha uma planilha própria. Um terceiro precisa de um campo diferente e a equipe duplica uma automação inteira para mudar uma regra.

No início, copiar é rápido. O custo aparece depois. Correções precisam ser replicadas, indicadores deixam de ser comparáveis, treinamento fica mais difícil e ninguém sabe qual versão contém a regra correta.

Uma arquitetura de processo mais saudável tenta localizar a diferença. A aprovação adicional é uma etapa configurável? A variante de ERP muda apenas o conector? O campo diferente pertence a um mapeamento? A exceção exige realmente uma jornada nova ou apenas uma regra diferente em um componente conhecido?

Isso não significa que toda particularidade precisa caber em configuração. Algumas diferenças mudam o problema de verdade e merecem um fluxo próprio. O ponto é fazer essa decisão conscientemente, em vez de deixar que a organização acumule forks por conveniência.

A análise recente sobre mudança de requisitos no autódromo de Buenos Aires ajuda a marcar esse limite. Quando o objetivo muda de verdade, é correto replanejar. Modularidade não deve servir para esconder uma alteração estratégica importante como se fosse apenas mais um parâmetro.

Automação e IA são mais úteis quando a variação está localizada

Processos altamente variáveis são tentadores para IA porque parecem difíceis de automatizar com regras. Às vezes faz sentido. Mas jogar um agente sobre um processo inteiro também pode esconder onde a complexidade realmente está.

Ao decompor a operação, normalmente surgem trechos previsíveis e trechos interpretativos.

Criar uma pasta, verificar se um identificador existe, atualizar um status e disparar um prazo são tarefas determinísticas. Entender uma resposta ambígua de cliente, classificar uma exceção ou extrair intenção de uma conversa pode justificar IA. Decidir uma exceção de alto impacto pode continuar humana.

Essa decomposição permite usar tecnologia proporcional ao problema. Também facilita avaliação: em vez de perguntar se “o agente de onboarding funciona”, a equipe mede se determinada capacidade resolve seu tipo de trabalho com qualidade e se a passagem para a próxima etapa permanece confiável.

É uma continuação natural da discussão sobre redesenhar processos antes de automatizá-los. Primeiro se decide o que deveria existir. Depois, modularidade ajuda a organizar capacidades reutilizáveis. Só então automação e IA entram nos pontos onde realmente geram escala.

Modularidade também cria complexidade

Há um contraponto importante. Transformar tudo em módulo pode produzir uma espécie de “LEGO corporativo” impossível de montar.

Se cada pequena regra virar uma opção, a organização troca dezenas de processos duplicados por centenas de configurações. Surgem dependências entre parâmetros, combinações que nunca foram testadas e uma operação que só algumas pessoas entendem.

Por isso, modularidade precisa de limites. Componentes devem representar capacidades estáveis e recorrentes, não qualquer diferença observada uma vez. Combinações mais frequentes merecem caminhos bem testados. Configurações precisam ser visíveis. E deve existir um momento em que uma variação deixa de ser saudável e passa a justificar outro desenho.

A própria LEGO continua investindo bilhões em capacidade fabril, centros de distribuição e tecnologia. Um sistema de peças reutilizáveis não elimina o trabalho de operar variedade. Ele torna essa variedade mais administrável.

O teste prático é observar onde o retrabalho se repete

Uma empresa não precisa redesenhar toda a arquitetura de processos para começar. Há um diagnóstico mais simples: procure o trabalho que reaparece em versões ligeiramente diferentes.

Quantos formulários pedem quase os mesmos dados? Quantas automações fazem 80% da mesma coisa? Quantos templates de projeto possuem etapas equivalentes com nomes diferentes? Quantas integrações repetem autenticação, tratamento de erro e monitoramento? Quantas exceções poderiam ser representadas por uma regra em vez de uma cópia?

Esses pontos são bons candidatos a capacidades compartilhadas.

O objetivo final não é ter o menor número possível de processos. É conseguir adicionar variedade com um custo marginal menor, sem perder clareza sobre o que muda para cada cliente.

Foi isso que tornou os resultados da LEGO interessantes além do mercado de brinquedos. Mais de 330 lançamentos em seis meses convivem com crescimento de receita, ganho de participação e investimento pesado em uma infraestrutura que desenvolve e escala tecnologia de produção. O caso não prova que modularidade explica o desempenho financeiro da companhia; seria uma inferência grande demais. Mas mostra que variedade e padronização não são opostos quando a padronização acontece na camada certa.

Para operações de onboarding, implantação e automação, essa é uma pergunta mais útil do que “como padronizar tudo?”: o que precisa ser comum para que possamos variar o restante sem recomeçar?