Bundling por dentro: quando áreas viram pacotes mal desenhados

Toda empresa carrega pacotes invisíveis.

O financeiro não é uma coisa só. É contas a pagar, fluxo de caixa, fechamento contábil, DRE gerencial, planejamento, tributário e relacionamento bancário. A TI também não. É infraestrutura, dado, sistema, segurança, suporte interno, automação e integração. O comercial também não. É prospecção, fechamento, customer success, operações de venda e pricing.

Quase nenhum desses pacotes foi desenhado. Eles cresceram por contratação, urgência e remendo. E quando tudo entra na mesma fila, a empresa começa a pagar um imposto que não aparece em lugar nenhum: atraso, retrabalho, decisão lenta e gente boa cansada.

Bundling e unbundling costumam aparecer numa conversa de estratégia como decisão de produto e preço: vendo tudo junto ou vendo peça por peça? Faço a suíte completa (caso Trainee) ou deixo o cliente escolher só o que usa (caso Zoho)? A conversa é útil. Mas para na tabela de preço.

Porque o pacote mais caro da empresa quase nunca está na prateleira. Está dentro do organograma.

O erro mais caro de bundling não é o de embalar produto pra vender. É o de embalar capacidade dentro da própria casa.

Esse texto é sobre essa segunda aplicação: a mais cara, a menos discutida, e a que toda empresa de médio porte que opero carrega sem perceber. O caso de criar empresa nova a partir de uma capacidade interna existe, é interessante e cabe no fim. Mas o jogo principal acontece dentro do organograma que já está em pé.

#Área não é arquitetura, é arqueologia de contratação

Quase nenhum desses pacotes foi desenhado. Eles cresceram por inércia. Alguém boa em planilha virou “financeiro”, aí o sócio contratou um analista, depois um gerente, depois separou contas a receber porque virou volume, depois o gerente virou diretor e contratou um controller. Vinte anos depois isso é “a área financeira”. Não é arquitetura. É arqueologia de contratação.

O sintoma do pacote por inércia é específico e fácil de reconhecer quando você sabe o que olhar: o cliente interno reclama, mas não consegue articular o que falta. Ele só sabe dizer que “tá demorando”, que “não atende”, que “tá ruim”. Não consegue nomear a peça que compraria isolada, porque essa peça nunca existiu formalmente dentro do pacote. Ela está difusa, atendida com a mão esquerda por alguém que tem outra prioridade no topo do dia.

Exemplo concreto, do tipo que vejo se repetir no portfólio: contas a pagar atrasa, fornecedor liga reclamando, o operacional sente friccionalmente todo dia. Mas o que dá visibilidade do CFO pro board é DRE fechado, é projeção de caixa, é covenant bancário. Então a peça que pesa pra operação fica empurrada com a mão esquerda dentro do pacote financeiro, e nunca vira prioridade até virar incidente. O pacote escondeu a peça do radar de quem decide.

Multiplique isso por cinco áreas e você tem uma empresa onde quase toda fricção operacional é fricção de pacote mal-desenhado, e quase ninguém chama pelo nome.

Toda área é um pacote. A pergunta é se foi desenhada, ou se virou pacote por inércia.

#Bundling e unbundling, sem aula de consultor

Antes de entrar na empresa, dois minutos sobre a lente.

Jim Barksdale, ex-CEO da Netscape, deixou a frase mais útil sobre o tema: só existem duas formas de ganhar dinheiro: bundling e unbundling. Não é uma escolha entre duas estratégias rivais. É um ciclo que se alterna, e que a maioria das indústrias percorre mais de uma vez.

Jornal era bundle: por um valor mensal você comprava notícia, classificado, opinião, esporte e palavras cruzadas. A internet separou cada peça: classificado pro Craigslist, opinião pro blog, entrevista longa pro podcast. Depois a assinatura única rebundlou os pedaços de novo. Música fez o mesmo caminho: álbum (bundle) → música avulsa no iTunes (unbundle) → Spotify (rebundle). Telecom, TV a cabo e banco estão em algum ponto do mesmo ciclo agora.

A tradução pro empresário não é “qual estratégia escolho hoje”. É em que ponto do ciclo eu estou. Meu pacote envelheceu e tá pedindo cirurgia? Meu mercado se separou e tá pedindo cola? A resposta certa depende do momento, não da convicção.

Agora a lente em uma linha, em português simples.

Quando pessoas diferentes valorizam partes diferentes de uma entrega, vender tudo junto costuma fazer sentido: cada um paga pelo pacote inteiro porque uma parte resolve muito pra ele, mesmo “pagando demais” pela outra metade. Quando todo mundo valoriza a entrega de forma parecida, separar as peças funciona melhor: cada peça precisa provar seu valor sozinha, sem subsidiar nada.

Isso é fácil de enxergar em produto e preço. O que quase ninguém enxerga é que a mesma lógica existe dentro da empresa.

Lá dentro, a “moeda” não é dinheiro. É atenção da liderança, prioridade na fila, gente alocada, velocidade de desbloqueio, espaço no comitê que decide trade-off. O CFO disputa headcount com o COO igual cliente disputa SKU na prateleira. A empresa tem mercados internos com economia equivalente à dos externos: clientes, preço (em atenção), oferta escassa, concorrência por recurso. Só que ninguém aplica a lente, porque ninguém percebeu que o mercado tava ali.

#O erro: mexer no organograma e achar que redesenhou a empresa

O erro que mais vejo no portfólio: o empresário faz reorg (mexe no organograma) e acha que mudou o pacote. Não mudou. Trocou o nome da caixa no slide do RH. Processo continua o mesmo. Dado continua na mesma planilha. Decisão continua passando pela mesma pessoa. O cliente interno continua sentindo a mesma fricção, agora com um título de gerente diferente no topo do e-mail.

Reorg não é mudança de pacote. Reorg sem mexer em processo, dado e decisão é mudança de papel de parede.

Pacote de verdade muda quem é dono do quê, qual cliente interno é servido, qual KPI vale, qual SLA existe, qual decisão deixou de subir e qual passou a subir. Sem isso, é teatro de organograma: caro, demorado, e com a vantagem perversa de parecer que algo aconteceu. Por seis meses ninguém cobra de novo, porque “acabamos de reestruturar”.

Por que reorg sozinho quase nunca resolve? Porque o organograma é só uma das camadas do pacote.

#As cinco camadas do pacote interno

Pacote interno não é só “departamento”. O pacote de uma capacidade vive em pelo menos cinco camadas, e cada uma pode estar junta ou separada de forma independente:

1. Produto/serviço. O que efetivamente é entregue ao cliente interno. (Um único relatório consolidado, ou três separados?)
2. Processo. Como o trabalho flui. (Uma fila de demandas, ou três com prazos diferentes?)
3. Dado. Qual fonte de verdade alimenta a decisão. (Um data warehouse, ou três planilhas que ninguém concilia?)
4. Time/organograma. Quem reporta pra quem. (Uma diretoria, ou três squads autônomos?)
5. Decisão. Quem decide o quê, com qual cadência. (Comitê único semanal, ou decisão delegada por escopo?)

Reorg mexe só na camada quatro. Por isso quase nunca resolve: processo, dado e decisão continuam exatamente onde estavam.

A boa notícia é que, uma vez que você enxerga as cinco camadas, fica difícil errar. Você pergunta, pra cada camada, se faz sentido junta ou separada, e quase sempre a resposta é diferente em cada uma. O time pode ficar junto enquanto o processo separa. O dado pode ficar junto enquanto a decisão separa. O desenho ganha resolução.

#Quando separar uma capacidade interna

O critério é simples: clientes internos heterogêneos pedindo coisas materialmente diferentes da mesma capacidade.

O caso típico é BI dentro de TI. O comercial quer um número rápido pra negociar hoje: tolera dado aproximado, exige velocidade. O financeiro quer um número fechado pra apresentar ao banco: exige rigor absoluto, tolera demora. A operação quer um alerta antes do problema virar incêndio: exige latência baixa, tolera escopo estreito.

Chamar essas três demandas de “BI” é cômodo, mas esconde que são três trabalhos diferentes. Quando entram na mesma fila, alguém sempre perde. E quem perde, quase sempre, é quem não tem risco regulatório, porque ninguém quer ser o responsável por relatório errado pra Receita. Então o calendário do financeiro dita o ritmo do comercial, que dita o ritmo da operação, que reclama, que monta a própria planilha por fora, que duplica capacidade, que recria o problema em outro canto do organograma.

Separar, nesse caso, é dar a cada cliente interno uma rota direta: KPI próprio, autonomia de prioridade e um contrato de SLA explícito, o prazo combinado de atendimento. Não precisa ser três times distintos no organograma. Pode ser três frentes dentro do mesmo time, com regras de prioridade públicas e tempo alocado por escopo. O que importa é que cada cliente interno tenha rota previsível, sem entrar na mesma fila do outro.

O sinal de que separou bem é discreto: o cliente interno deixa de reclamar e passa a ter opção. Ele sabe quanto custa, quanto demora, quem responde. Não tem fila. Tem contrato.

Cuidado que vale sinalizar: separar sem governança vira silo. A capacidade fica autônoma, mas perde a coerência: três frentes de BI usando ferramentas diferentes, sem reconciliar definições, e em seis meses três fontes de verdade conflitantes. O remédio não é voltar a juntar tudo; é contrato explícito de interface entre as peças, padrão comum onde faz sentido, autonomia onde não muda nada.

Anti-padrão a evitar antes que vire moda interna: “criar um squad” como sinônimo de separar. Squad sem KPI próprio, sem autonomia real de prioridade e sem cliente interno definido é só um nome novo pra um grupo de WhatsApp. O pacote continua intacto embaixo, agora com um título mais bonito no Notion.

#Quando juntar capacidades espalhadas

O critério oposto, igualmente claro: mesma demanda, atendida em pedaços por times diferentes, e ninguém é dono do resultado integrado.

O caso clássico no portfólio é dado. Comercial faz seu BI. Financeiro faz o dele. Operação faz o terceiro. Cada um tem sua planilha, sua definição de “cliente ativo”, sua régua de “receita reconhecida”. Toda decisão de board começa com vinte minutos de debate sobre qual planilha vale, e geralmente termina sem conclusão porque o dado nunca foi reconciliado de verdade.

Juntar, nesse caso, é centro de excelência, plataforma compartilhada, time único com mandato cruzado. Torre de controle. Uma única definição de cada métrica, um único pipeline de dado, uma única superfície onde todo mundo bate quando precisa de número.

O cuidado é específico e importante: juntar mal vira gargalo político. O time central vira o vilão de todo mundo, porque herda todas as reclamações sem herdar nenhum dos contextos. Comercial reclama que a “área de dados” não entende velocidade. Financeiro reclama que não entende rigor. Operação reclama que não entende prioridade. O time central tenta agradar os três, falha com os três, e em dezoito meses alguém propõe “vamos federar isso de novo”.

O sinal de que juntou bem é o oposto do anterior: o cliente interno final pede uma coisa e recebe. Não escolhe qual time acionar. Não monta a planilha por fora. Não duplica esforço.

Juntar capacidade interna só funciona quando reduz a quantidade de decisões que o cliente interno precisa tomar, não quando reduz a quantidade de times que entregam. Juntar pra “ter um único ponto de contato” sem reduzir a decisão do cliente é só mudar a porta onde ele bate. O ranger continua, agora redirecionado. A medida certa não é o número de times nem o tamanho do organograma: é o número de decisões que sumiu do prato do cliente interno final.

#A sequência que funciona: separar pra entender, juntar pra escalar

Empresa que tenta resolver pacote interno num movimento só quase sempre erra. A sequência que vejo funcionar no portfólio é dois tempos, em ordem específica.

Primeiro, separe pra mapear. Abra o pacote nas peças que ele escondia. Cada peça ganha dono, KPI, cliente interno definido e SLA explícito. É feio. É granular. Parece fragmentação. Vai gerar reclamação interna do tipo “agora tá tudo separado, ficou pior”. Aguenta. Esse momento é onde você descobre quais peças existiam mas estavam invisíveis, quais ninguém tinha, e quais não precisam existir.

Depois, remonte conscientemente pra escalar. Com cada peça já provada (ou não) isoladamente, você decide quais combinar. Agora com desenho, não por inércia. Algumas voltam ao pacote original. Outras viram pacote novo com peças que vieram de áreas diferentes. Outras ficam autônomas de vez. E algumas, as mais valiosas dessa fase, descobrem-se desnecessárias e morrem sem que ninguém sinta falta.

Quem só faz a primeira metade vive em sopa de squads sem coesão, com custo administrativo subindo e ninguém respondendo pelo todo. Quem só faz a segunda, remonta sem antes separar, não sabe o que tá embalando. Empacota disfunção e chama de plataforma. Por seis meses parece organizado. No sétimo, o pacote novo recriou todos os problemas do velho, com nome diferente.

Esse padrão de dois tempos é o que separa reformulação organizacional de verdade do ciclo eterno de reorg. E é também o que distingue o empresário que desenha empresa do que reage a ela.

#O caso raro: quando uma capacidade vira empresa

Há um caso em que a capacidade interna deixa de ser peça do pacote e vira empresa própria. O padrão Amazon/AWS é o exemplo manjado: a infraestrutura interna ficou tão boa e tão demandada, primeiro por outras áreas, depois por terceiros, que mantê-la presa ao uso interno virou desperdício óbvio. No Brasil aparece em escala menor: software interno de gestão de obra que vira SaaS, método de previsão de demanda que vira braço de consultoria, squad de pricing que vira ferramenta licenciada.

Mas é raro. E o que torna o spin-out viável é o critério, não a vontade. Três precisam estar satisfeitos antes do anúncio:

1. Demanda externa já bate na porta. Alguém de fora já pediu pra comprar, repetidamente, sem esforço de venda seu. Se a demanda precisa ser construída do zero, é produto novo, não spin-out.
2. A governança consegue separar. Contrato com a empresa-mãe, conflito de interesse mapeado, equity decidido antes do PowerPoint. Sem isso escrito, o spin-out cria fricção que custa mais do que rende.
3. O time consegue se virar sozinho. Captação própria de cliente, roadmap próprio, P&L separado de verdade. Se a sobrevivência depende de contrato cativo com a mãe, é divisão, não spin-out.

O erro clássico é spin-out por status: “vamos ter uma startup no portfólio”. Vira incubação cara, distrai a operação principal, e em um ano volta pro pacote com cicatriz. O critério honesto, sem romance: a capacidade vira empresa quando mantê-la amarrada ao pacote interno custa mais do que cuidar de uma empresa nova. Não antes. E quase sempre é mais tarde do que parece.

#Diagnóstico rápido

Antes de mexer no organograma, responda quatro perguntas. Elas resolvem 80% dos casos.

1. Essa área foi desenhada, ou só acumulou funções ao longo dos anos? Se a resposta honesta é “nem sei como ela se formou”, já é diagnóstico.
2. Quem ela atende dentro da empresa, e esse cliente consegue dizer o que precisa? Se ele só sabe dizer que “tá ruim” mas não nomeia a peça que falta, o pacote escondeu as peças do próprio cliente.
3. As demandas que chegam nela têm ritmos, riscos e urgências incompatíveis? Se sim, candidato a separar, no formato dois tempos.
4. Existe outra área fazendo pedaços parecidos do mesmo trabalho, sem dono claro? Se sim, candidato a juntar, desde que o objetivo seja reduzir decisões do cliente final, não caixas no organograma.

Não é checklist completo. É filtro pra separar pacote ok de pacote precisando de cirurgia. A maioria passa sem problema. Os que falham geralmente são os que estão custando caro há anos sem nome.

Se a resposta vier confusa, talvez o problema não seja gente. Talvez seja desenho.

#Operação redonda começa no desenho

Errar pra fora (bundling de pricing, portfólio de produto) significa receita perdida, quase sempre reversível com mudança de tabela numa semana. Custa, mas é cirúrgico.

Errar pra dentro custa diferente, e cumulativamente. Time desmotivado servindo o cliente interno errado. Capacidade que poderia valer muito atrofiada amarrada no pacote errado. Decisão lenta porque três times empurram a mesma bola e ninguém é dono. Software duplicado porque cada área comprou o seu: a comercial achou que TI demorava e comprou a própria ferramenta de BI; o financeiro fez igual; agora são três contratos e nenhum integra. Retrabalho permanente porque o dado mora em três fontes que ninguém reconcilia. Gente boa cansada de empurrar bola dentro de pacote mal-desenhado.

O pacote interno mal-desenhado é o imposto invisível mais alto que vejo no portfólio, e o único que ninguém vê na DRE.

Reformular pra dentro não custa mais que reorganizar. Mas raramente entra em pauta porque o pacote parece “natural”: ninguém olha pro “departamento financeiro” e pensa “isso é uma decisão de bundling que alguém tomou, ou deixou de tomar, há quinze anos”. Trata como geografia da empresa, não como desenho. E geografia, por definição, não se discute.

O ponto não é aprender mais uma palavra de estratégia. É olhar pra dentro e perguntar: o que está junto porque faz sentido, e o que está junto só porque foi acumulando ao longo dos anos?

Toda empresa carrega pacotes invisíveis. Alguns funcionam. Outros escondem atraso, retrabalho, disputa de prioridade e custo político que nunca aparece numa linha do P&L.

Por isso o desenho vem antes da operação. Antes da reunião que decide (cadência operacional), vem o desenho do pacote que define quem decide o quê: sem ele, a reunião certa convida as pessoas erradas. Antes do sistema operacional que orquestra motores de IA (modelo é combustível), vem o desenho de quais motores ele orquestra, e cada motor é, ele mesmo, uma decisão de bundling sobre quais peças de trabalho ficam juntas.

Quem opera pacote errado nunca alcança operação redonda. Só fica mais eficiente em empurrar o mesmo problema.