PARTE III — A EMPRESA AUMENTADA
Capítulo 10 / 21
O organograma vai mudar
O organograma tradicional mostra quem responde a quem. A Empresa Aumentada precisa também mostrar quem observa, quem decide, quem executa, que sistema fornece contexto e quando uma exceção muda de nível.
Durante mais de um século, o organograma foi uma das imagens mais reconhecíveis da organização moderna.
Caixas.
Linhas.
Cargos.
Hierarquias.
Direção no topo.
Áreas funcionais abaixo.
Equipas distribuídas por níveis.
O organograma responde bem a uma pergunta:
Quem responde a quem?
Mas responde mal a várias outras.
Como circula informação?
Onde vive o processo?
Que sistemas sustentam cada função?
Que decisões são automáticas?
Que agentes executam tarefas?
Quem recebe exceções?
Que dados alimentam uma decisão?
O que acontece quando uma operação atravessa quatro departamentos?
À medida que empresas incorporam agentes inteligentes, automações e sistemas mais autónomos, estas perguntas tornam-se centrais.
O organograma não desaparece.
Torna-se insuficiente.
1. Autoridade não é fluxo de trabalho
Considere uma empresa simples.
CEO.
Diretor Comercial.
Diretor de Operações.
Diretor Financeiro.
Gerentes.
Equipas.
O organograma mostra autoridade.
Mas uma venda real pode atravessar:
marketing → comercial → financeiro → operações → logística → atendimento.
Nenhum desses fluxos aparece claramente.
Por isso organizações sempre precisaram de outros mapas:
- fluxogramas;
- BPMN;
- SIPOC;
- RACI;
- jornadas;
- mapas de sistema;
- value streams.
A Empresa Aumentada não substitui essas ferramentas.
Precisa combiná-las numa representação mais operacional.
2. O Operating Map
Chamaremos a essa representação Operating Map da Empresa Aumentada.
Ele deve mostrar cinco coisas.
1. Missões
Que resultado cada função procura.
2. Capacidade
Pessoas, agentes e automações.
3. Sistemas
Onde o trabalho acontece.
4. Fluxos
Como informação e ação atravessam a organização.
5. Exceções
Quando e para quem uma decisão sobe.
É menos um organograma.
Mais um mapa do sistema operacional da empresa.
3. Um organograma tradicional
Útil.
Mas incompleto.
Agora introduzimos capacidade computacional.
4. Um organograma híbrido
Já conseguimos ver uma arquitetura diferente.
Mas ainda falta uma dimensão.
Agentes não vivem apenas debaixo de chefias.
Eles dependem de sistemas e dados.
5. A camada invisível
Por baixo da estrutura existe outra arquitetura.
CRM.
ERP.
Email.
WhatsApp.
e-commerce.
Base de dados.
Documentos.
BI.
APIs.
Pagamentos.
Calendário.
Uma pessoa pode atravessar vários sistemas.
Um agente também.
Por isso precisamos representar esta camada.
Esta representação aproxima-se mais da realidade.
6. O organograma deixa de mostrar apenas headcount
Hoje um gestor pode dizer:
“Tenho uma equipa de 12 pessoas.”
Amanhã essa descrição pode ser insuficiente.
Pode ter:
- 6 pessoas;
- 8 agentes;
- 15 automações;
- 3 fornecedores;
- 5 sistemas críticos.
A capacidade total não é igual ao headcount.
Isso altera a forma como pensamos departamento.
7. Capability Headcount
Podemos introduzir um termo gerencial:
Capability Headcount.
Não como substituto de headcount humano.
Mas como complemento.
A pergunta:
Quantas unidades de capacidade operacional existem nesta função e como são compostas?
Exemplo:
Comercial
4 vendedores.
1 coordenador.
1 Sales Agent.
1 Research Agent.
1 CRM Agent.
2 fluxos de trabalho.
Isto permite discutir capacidade sem confundir pessoas com software.
8. A estrutura híbrida precisa de ownership humano
Mesmo quando agentes executam, cada função precisa de responsável.
Exemplo:
AI Sales Coordinator
responsável: Diretor Comercial.
Stock Agent
responsável: Responsável de Supply.
Collections Agent
responsável: Financeiro.
Sem responsável, agentes tornam-se ativos órfãos.
Quando algo falha, ninguém sabe quem responde.
Quando política muda, ninguém atualiza.
Quando custo sobe, ninguém decide.
Ownership é parte da arquitetura.
9. RACI deixa de ser suficiente?
RACI continua útil.
Responsible.
Accountable.
Consulted.
Informed.
Mas ambientes híbridos podem precisar distinguir execução humana e computacional.
Podemos adicionar uma camada operacional sem destruir o framework.
Responsible
Quem executa a atividade.
Pode ser pessoa ou agente.
Accountable
Quem responde pelo resultado.
Humano ou função institucional.
Consulted
Quem fornece contexto ou decisão.
Informed
Quem precisa saber.
System / Agent
Que capacidade técnica executa ou suporta.
Não é necessário criar uma nova sigla para tudo.
É suficiente tornar explícito aquilo que antes estava invisível.
10. O mapa de autoridade
Outro elemento importante:
autoridade não segue necessariamente o mesmo caminho que execução.
Um agente pode executar.
Mas uma pessoa mantém autoridade.
Um sistema pode recomendar.
Outro valida.
Uma pessoa aprova.
Podemos representar:
Isto evita a ilusão de que autonomia elimina cadeia de responsabilidade.
11. O mapa de atenção
Além de autoridade, precisamos mapear atenção.
Onde humanos ainda precisam olhar?
Todo dia?
Toda semana?
Apenas em exceção?
Podemos classificar.
Nível 1 — Atenção contínua
Humano participa diretamente.
Nível 2 — Atenção por aprovação
Sistema prepara; humano decide.
Nível 3 — Atenção por exceção
Humano entra apenas quando limiar é ultrapassado.
Nível 4 — Auditoria periódica
Operação autónoma com revisão amostral.
Quanto mais madura a operação, mais atenção humana pode ser deslocada para níveis superiores.
12. O mapa de exceções
Uma empresa pode ter hierarquia clara e ainda sofrer com exceções mal desenhadas.
Perguntas:
Se stock entra em risco, quem recebe?
Se fraude é suspeita, quem decide?
Se cliente enterprise ameaça cancelar, para onde vai?
Se agente encontra política contraditória, quem resolve?
O Operating Map precisa mostrar estas rotas.
Exceção sem destino cria paralisia.
13. Exceções são parte do design, não falhas
Muitas empresas desenham processo apenas para o caso ideal.
Depois consideram exceção “um problema”.
Mas exceções são inevitáveis.
Um bom processo define:
- quais exceções são esperadas;
- quais são raras;
- quem responde;
- qual SLA;
- que dados devem acompanhar.
A Empresa Aumentada deve possuir exception architecture.
14. O exemplo das dez farmácias
Vamos representar a rede.
Direção
Objetivos e políticas.
AI Retail Operations Coordinator
Observa rede.
Distribui trabalho.
Store Layer
Cada loja possui:
- pessoas;
- stock;
- POS;
- atendimento.
Agentes transversais
- stock;
- compras;
- pricing;
- atendimento;
- reporting.
Sistemas
ERP.
CRM.
POS.
Financeiro.
Fornecedores.
Aqui o organograma deixa de ser vertical.
Torna-se rede.
15. Estrutura local versus capacidade transversal
Uma das vantagens de agentes é a capacidade de operar transversalmente.
Uma pessoa pode estar associada a uma loja.
Um agente de stock pode observar dez lojas.
Um agente de marketing pode servir várias marcas.
Um agente financeiro pode consolidar múltiplas unidades.
Isto cria um desenho interessante:
pessoas locais + inteligência transversal.
Em redes, franquias, clínicas, farmácias e multi-store, esta arquitetura pode ser particularmente poderosa.
16. Shared Agent Services
Podemos chamar a essa camada:
Shared Agent Services.
Exemplos:
- Research;
- Translation;
- Compliance;
- Reporting;
- Procurement intelligence;
- CRM hygiene;
- Content adaptation.
Vários departamentos podem consumir a mesma capacidade.
Isto reduz duplicação.
Mas exige governação.
17. O risco da centralização agentic
Uma capacidade transversal pode tornar-se gargalo.
Se todos os agentes dependem de um único coordenador.
Se toda decisão passa por um único modelo.
Se uma falha paralisa tudo.
Arquitetura precisa de resiliência.
Fallback.
Redundância.
Limites.
Degradação controlada.
Não queremos trocar dependência humana por dependência computacional única.
18. O princípio da autonomia local
Sempre que possível, decisões simples devem acontecer perto do contexto.
Uma loja deve resolver aquilo que pode resolver.
Um agente local deve agir dentro de limites.
O centro recebe apenas:
- consolidação;
- exceção;
- risco;
- decisão transversal.
Isto reduz latência.
E evita mega-orquestradores.
19. Estruturas matriciais tornam-se ainda mais comuns
Empresas já utilizam matrizes.
Uma pessoa pode responder a área funcional e unidade de negócio.
Agentes tornam isto ainda mais natural.
Um Research Agent pode trabalhar para:
comercial;
marketing;
produto.
Um Compliance Agent pode supervisionar:
financeiro;
vendas;
operações.
Um Translation Agent pode servir múltiplos países.
O mapa precisa mostrar relações funcionais, não apenas hierarquia.
20. O Operating Map como ativo vivo
Um organograma costuma ser atualizado quando alguém entra ou sai.
Um Operating Map precisa mudar mais frequentemente.
Quando:
- adicionamos agente;
- mudamos integração;
- alteramos policy;
- mudamos responsável;
- automatizamos processo;
- criamos novo canal;
- retiramos sistema.
Ele deve ser tratado como documentação viva.
21. Versão do Operating Map
Assim como agentes têm versão, arquitetura também.
Operating Map v1.3
Data.
responsáveis.
Mudanças.
Isto parece excesso para empresa pequena.
Mas torna-se valioso à medida que automação cresce.
Porque reduz conhecimento invisível.
22. O mapa de dependências
Uma operação pode depender de dezenas de serviços.
Exemplo:
Follow-up Agent depende de:
CRM.
Modelo.
WhatsApp API.
Base de políticas.
Calendário.
Se uma dependência falha, o que acontece?
O Operating Map deve revelar dependências críticas.
23. O mapa de dados
Também precisamos mostrar fluxo de informação.
Origem.
Transformação.
Consumo.
Retenção.
Exemplo:
lead chega do Meta.
Vai para CRM.
Agente qualifica.
Resultado alimenta pipeline.
Financeiro recebe venda.
BI agrega.
Este mapa é essencial para privacidade, segurança e qualidade.
24. O mapa de decisão
Quem decide?
Podemos distinguir:
Decision Type 1 — Regra
Automatizável.
Decision Type 2 — Julgamento com limite
Agent + humano.
Decision Type 3 — Estratégica
Humano.
Decision Type 4 — Emergência
Humano com suporte computacional.
Mapear decisões ajuda a desenhar autonomy.
25. O Operating Map completo
Podemos então representar uma função como sete camadas.
- Missão.
- Pessoas.
- Agentes.
- Processos.
- Sistemas.
- Dados.
- Decisões e exceções.
Tudo ligado a KPIs.
26. O template AtlasHub
Missão da função
Qual resultado.
Human responsáveis
Quem responde.
Human Roles
Quem participa.
Agents
Que capacidade agentic.
Systems
Que ferramentas.
Inputs
Que dados entram.
Outputs
Que resultado sai.
Decisions
Quem decide.
Exceptions
O que sobe.
KPIs
Como medimos.
Dependencies
O que pode falhar.
Este template pode ser aplicado a qualquer área.
27. O impacto na gestão de pessoas
Se o mapa muda, funções humanas também mudam.
Uma pessoa pode deixar de ser:
“analista que prepara relatório”.
Passar a ser:
“responsável de performance que supervisiona dados, agentes e decisões”.
Um vendedor pode deixar de gerir CRM manualmente.
Passar a dedicar mais tempo a negociação.
Um gestor pode deixar de recolher status.
Passar a gerir exceções e capacidade.
Descrição de cargos precisa evoluir.
28. Performance humana e agentic
KPIs precisam ser separados.
Não devemos misturar performance de pessoa com falha de agente.
Se sistema atrasou, não atribuir automaticamente culpa ao operador.
Se agente realizou tarefa, não premiar pessoa apenas por volume gerado automaticamente.
A arquitetura de avaliação precisa reconhecer origem da capacidade.
29. O manager da Empresa Aumentada
Um gestor futuro pode precisar de competências em:
- desenho de processo;
- literacia de dados;
- governação;
- análise de risco;
- gestão de agentes;
- interpretação de métricas;
- arquitetura de decisão.
Não precisa ser programador.
Mas precisa entender o sistema.
30. O novo middle management
Muito se especula que IA eliminará middle management.
Talvez algumas funções de coordenação manual diminuam.
Mas coordenação não desaparece.
Ela muda.
Gestores podem passar de:
recolher informação;
distribuir tarefas;
lembrar prazos;
para:
definir contexto;
ajustar política;
resolver exceções;
desenvolver pessoas;
monitorizar capacidade;
redesenhar sistema.
Middle management pode tornar-se mais técnico em sentido organizacional, não necessariamente de programação.
31. O risco do organograma fantasma
Existe um risco curioso.
A empresa formal mantém um organograma.
Mas a operação real acontece noutro.
Pessoas dependem de automações que ninguém documentou.
Agentes executam tarefas sem responsável.
Planilhas substituem sistemas.
WhatsApp torna-se fluxo de trabalho.
Isto cria um organograma fantasma.
O Operating Map serve precisamente para revelar a operação real.
32. A arquitetura precisa ser legível
Complexidade técnica não pode tornar-se desculpa para opacidade.
Um diretor deve conseguir olhar para o mapa e entender:
- quem faz;
- quem decide;
- que agente atua;
- que sistema suporta;
- onde estão riscos.
A arquitetura precisa ser comunicável.
Caso contrário, a empresa perde governação.
PRINCÍPIO
Se ninguém consegue explicar como a operação funciona, ninguém consegue governá-la.
33. A Empresa Aumentada como organismo
Voltamos à metáfora visual.
O organograma é esqueleto.
Os processos são músculos.
Dados são sinais.
Sistemas são órgãos.
Agentes são capacidade cognitiva distribuída.
governação é sistema de controlo.
Pessoas definem intenção e responsabilidade.
Nenhuma parte sozinha é a empresa.
É a coordenação que cria vida operacional.
A EQUAÇÃO
O Operating Map deve mostrar onde cada variável é criada.
RECEITA ↑
Quais funções geram aquisição, conversão, retenção e expansão?
CUSTOS ↓
Onde existe retrabalho, espera e coordenação manual?
VELOCIDADE ↑
Onde existem handoffs?
CONTROLO ↑
Onde decisões não são observáveis?
Um bom mapa transforma abstração em diagnóstico.
34. O passo seguinte
Agora conseguimos ver o agente.
E conseguimos vê-lo dentro da organização.
Surge então o próximo salto.
Quando existem vários agentes, eles precisam trabalhar em conjunto.
Um identifica oportunidade.
Outro pesquisa.
Outro simula margem.
Outro prepara conteúdo.
Outro consulta logística.
Alguém precisa coordenar.
Pode ser uma pessoa.
Pode ser um agente.
Pode ser uma arquitetura híbrida.
É aí que entramos no nível mais avançado desta Parte III.