PARTE V — A EQUAÇÃO DA EMPRESA AUMENTADA

Capítulo 21 / 21

Por onde começar amanhã

A Empresa Aumentada não começa com uma transformação total. Começa quando uma organização escolhe um problema real, mede o estado atual, desenha uma capacidade melhor e aprende com a primeira execução.

Depois de quase todo livro sobre tecnologia, existe um risco.
O leitor termina motivado.
Fecha o livro.
Volta para a empresa.
E não sabe por onde começar.
Existem demasiadas possibilidades.
Atendimento.
Vendas.
Compras.
Financeiro.
Marketing.
Logística.
CRM.
Relatórios.
Agentes.
Automação.
Integrações.
Dados.
A tentação é criar uma lista de vinte projetos.
Ou comprar uma plataforma que promete resolver todos.
Eu sugiro o oposto.
Comece com uma unidade pequena o suficiente para ser controlada.
Mas importante o suficiente para produzir aprendizagem real.
A regra é:

1 processo

1 problema

1 objetivo

1 capacidade inteligente

30 dias

Não porque 30 dias sejam suficientes para transformar uma empresa.
Mas porque são suficientes para impedir que a transformação permaneça apenas como intenção.

1. Não começar pela tecnologia

A primeira reunião não deveria perguntar:

“Que IA vamos usar?”

Deveria perguntar:

“Onde estamos a perder valor?”

Exemplos:

leads sem resposta;
stock em rutura;
horas de receção;
propostas sem follow-up;
fornecedor sem acompanhamento;
relatórios produzidos manualmente;
documentos que demoram;
clientes que repetem informação;
aprovações que bloqueiam fluxo.
A tecnologia entra depois.

2. O AI Opportunity Walk

Antes de workshop, software ou arquitetura sofisticada, faça uma caminhada pela operação.
Literal ou metafórica.
Observe um dia.
Pergunte às pessoas:

“O que faz todos os dias que considera repetitivo?”
“Onde espera?”
“O que precisa procurar?”
“O que copia de um lugar para outro?”
“O que costuma ser esquecido?”
“Que decisão sobe para a chefia sem realmente precisar?”
“Que problema chega tarde?”
“Que informação você gostaria de ter antes?”

Estas perguntas encontram oportunidades reais.

3. Procurar fricção, não glamour

Os primeiros bons casos de uso raramente são os mais impressionantes.
Podem ser:

reconciliar;
classificar;
resumir;
lembrar;
transferir contexto;
preparar decisão.
São menos interessantes numa conferência.
Mas podem ser muito valiosos numa empresa.

4. O AI Opportunity Map

Depois de recolher oportunidades, classificar em quatro dimensões.

Impacto

Se funcionar, quanto valor pode criar?

Viabilidade

Dados e sistemas permitem executar?

Risco

Qual o custo de errar?

Esforço

Quanto custa implementar e manter?
Podemos acrescentar uma quinta:

Frequência

Acontece vezes suficientes para justificar?

5. Não escolher o maior problema primeiro

O maior problema pode exigir:

ERP novo;
dados inexistentes;
mudança cultural;
integração complexa;
meses de trabalho.
O primeiro caso precisa também de ensinar a organização.
Escolha algo:
importante;
delimitado;
observável;
reversível;
com responsável;
com baseline.

6. O caso ideal de 30 dias

Sinais de bom primeiro caso:

ocorre diariamente ou semanalmente;
consome horas;
possui regras relativamente claras;
dados já existem;
impacto pode ser medido;
risco é limitado;
existe equipa interessada;
podemos operar em shadow mode.

7. Semana 0 — definir o dono

Antes dos 30 dias, uma condição.
Existe Process responsável.
Não apenas TI.
Não apenas consultoria.
Não apenas “equipa de IA”.
Alguém do negócio responde pelo resultado.
Sem responsável, o projeto vira experimento permanente.

8. Dia 1 — definir o problema

Escrever numa frase.
Ruim:

“Queremos usar IA em vendas.”

Melhor:

“32% das propostas não recebem follow-up dentro de 48 horas.”

Ruim:

“Queremos IA no stock.”

Melhor:

“Descobrimos rutura de SKUs prioritários quando a disponibilidade já foi perdida.”

Problema bom é observável.

9. Dia 2 — baseline

Medir antes.
Exemplo:

volume;
tempo;
erro;
custo;
conversão;
escalamento;
backlog.
Se não existe dado histórico perfeito, fazer amostragem.
O objetivo é ter referência suficiente.

10. Dias 3–4 — mapear o processo real

Não o processo no manual.
O real.
Quem recebe?
O que abre?
Que sistema?
Que planilha paralela?
Que exceção?
Que atalho?
Que mensagem?
É normal descobrir que processo oficial e processo real são diferentes.

11. O Process Reality Map

Diagrama do manuscrito: Por onde começar amanhã
O mapa não deve envergonhar a equipa.
Deve revelar fricção.

12. Dia 5 — eliminar antes de automatizar

Perguntar sobre cada etapa:

precisa existir?
pode ser simplificada?
pode ser combinada?
quem realmente precisa aprovar?
que dado já existe?
Só depois desenhar IA.

13. Dias 6–7 — Result Map

Preencher:

Problema

O quê.

Mecanismo

Como a nova capacidade pode mudar.

Métrica operacional

O que observaremos.

Equação

Receita, Custos, Velocidade, Controlo.

Risco

O que pode piorar.
Agora temos business case inicial.

14. Dias 8–9 — escolher nível de autonomia

Não começar automaticamente em full autonomy.
Escolher:

Assistivo

Sugere.

Copilot

Prepara dentro do fluxo.

Supervisionado

Executa com aprovação.

Autónomo limitado

Executa dentro de política.
Para primeiro sprint, frequentemente assistivo ou supervisionado é suficiente.

15. Dia 10 — Agent Charter

Se o caso exige agente:

missão;
trigger;
contexto;
conhecimento;
ferramentas;
permissões;
KPIs;
escalamento;
responsável.
Se não consegue preencher, ainda não está pronto para construir.

16. Dias 11–13 — preparar dados

Verificar:

fonte oficial;
campos;
qualidade;
acesso;
atualização;
duplicação;
privacidade;
sensibilidade.
Muitos projetos de “IA” são, na verdade, projetos de dados.
É melhor descobrir cedo.

17. Dias 14–16 — construir a primeira versão

Objetivo:
mínimo sistema que testa a hipótese.
Não plataforma definitiva.
Não interface perfeita.
Não arquitetura para cinquenta países.
Uma capacidade funcional.

18. Dia 17 — teste offline

Casos históricos.
Normais.
Exceções.
Dados em falta.
Conflito.
Inputs adversos.
Perguntar:

fez a coisa certa?
explicou?
escalou?
respeitou limite?

19. Dias 18–20 — shadow mode

Agora entram casos reais.
O sistema observa.
Sugere.
Humano continua a executar.
Comparamos:

decisão;
qualidade;
tempo;
erro.
Shadow mode reduz risco e produz evidência.

20. Dia 21 — revisão de gaps

O que falhou?
Pode ser:

dados;
política;
integração;
prompt;
ferramenta;
processo;
responsável.
Não assumir que tudo é “problema do modelo”.
Diagnóstico correto importa.

21. Dias 22–25 — piloto limitado

Definir envelope.
Exemplo:
apenas um segmento.
uma loja.
um tipo de pedido.
um horário.
um valor máximo.
Agora o sistema executa dentro de limites.

22. Human override

Durante piloto, mecanismo de intervenção precisa ser simples.
Pausar.
Assumir caso.
Reverter.
Reportar erro.
Sem isto, equipa perde confiança.

23. Dias 26–27 — medir

Comparar baseline.

Resultado

Mudou?

Qualidade

Errou?

Tempo

Reduziu?

Escalamento

Quanto trabalho humano continua?

Custo

Quanto custou?

Experiência

Piorou algo?

24. Dia 28 — Value Realization Review

Preencher o mapa.
Valor realizado.
Potencial.
TCO.
Riscos.
Lições.
Não maquiar.

25. Dia 29 — decisão

Apenas quatro opções.

Escalar

Evidência forte.

Continuar piloto

Precisamos de mais dados.

Redesenhar

Hipótese faz sentido, arquitetura não.

Parar

Não cria valor suficiente.
Parar é decisão legítima.

26. Dia 30 — institucionalizar aprendizagem

Mesmo se projeto parar, registrar:

o que aprendemos;
que dados faltam;
que política precisamos;
que integração foi criada;
que capacidade pode ser reutilizada.
A empresa deve ficar mais inteligente depois de cada experimento.

27. O sprint não termina no agente

Se piloto funciona, agora começa gestão.
Precisamos de:

responsável;
versão;
monitorização;
custo;
revisão;
incidentes;
atualização de conhecimento;
segurança.
Produção é começo de ciclo.
Não fim de projeto.

28. O Augmented Sprint Canvas

Podemos condensar o sprint numa página.

1. Problema

2. Baseline

3. Processo

4. Hipótese

5. Equação

6. Autonomia

7. Agent Charter

8. Risco

9. Pilot Scope

10. Métricas

11. Value responsável

12. Decision Gate

29. O primeiro portfolio

Depois do primeiro caso, não criar vinte.
Criar portfólio.
Exemplo:

Run

Casos em produção.

Pilot

Em teste.

Discover

Em avaliação.

Stop

Encerrados.
Isto cria disciplina.

30. Limite de WIP

Transformação também sofre com trabalho em progresso.
Dez pilotos simultâneos consomem equipas.
Melhor:
poucos;
bem medidos;
com responsável.
Aplicar princípio de WIP limit também à inovação.

31. O Augmented Transformation Board

Diagrama do manuscrito: Por onde começar amanhã
Cada caso tem responsável, valor esperado e data de decisão.

32. Priorizar por capacidade reutilizável

Depois de provar valor, procurar casos que reutilizam:

integrações;
memória;
identidade;
observabilidade;
ferramentas;
governação.
É assim que plataforma emerge.

33. A ordem recomendada para uma PME

Uma progressão pragmática pode ser:

1. Visibilidade

Briefings, dashboards, exceções.

2. Coordenação

Routing, follow-up, handoffs.

3. Execução assistida

Copilots e preparação.

4. Autonomia limitada

Ações de baixo risco.

5. Coordenação multiagente

Somente quando necessário.
Isso reduz salto de complexidade.

34. A ordem recomendada para empresa maior

Pode existir em paralelo:

governação foundation

Identity, logging, risk tiers.

Domain pilots

Comercial, operações, financeiro.

Shared capabilities

Research, knowledge, translation.

AgentOps

Monitorização e control tower.

Scale

Portfólio.
Mas ainda assim: casos reais primeiro.

35. Não esperar pela arquitetura perfeita

Existe outro extremo.
A empresa passa seis meses definindo governação antes de testar uma única capacidade.
Alguma fundação é necessária.
Mas aprendizagem real exige operação.
A melhor arquitetura emerge da interação entre princípio e prática.

36. O mínimo de governação para começar

Mesmo num pequeno piloto:

responsável;
missão;
dados permitidos;
ações permitidas;
logs;
human override;
kill criteria.
Não é burocracia.
É estrutura mínima.

37. O papel da liderança nos primeiros 30 dias

Não construir.
Não escrever prompt.
Não escolher modelo.
A liderança deve:

escolher problema;
proteger tempo da equipa;
definir limite;
remover bloqueio;
avaliar resultado;
decidir.
É uma função de direção.

38. O papel das pessoas da operação

Elas conhecem atalhos, exceções e realidade.
Não desenhar sistema sem elas.
Um processo desenhado apenas por direção ou TI costuma automatizar a versão imaginada do trabalho.
Não o trabalho real.

39. O papel de IT / Engineering

Garantir:

integração;
segurança;
identidade;
observabilidade;
confiabilidade;
versionamento.
Não escolher sozinho política de negócio.

40. O papel de Risk / Legal / Compliance

Entrar proporcionalmente ao risco.
Não bloquear tudo.
Não aparecer apenas no final.
Ajudar a definir envelope.
governação boa acelera porque reduz incerteza.

41. O papel do Value responsável

Perguntar continuamente:

“Estamos realmente produzindo o valor que justificou este projeto?”

É a pessoa que evita demo permanente.

42. A reunião semanal de 20 minutos

Um piloto não precisa de steering committee gigantesco.
Uma revisão curta:

o que aconteceu;
métrica;
erros;
exceções;
custo;
decisão da semana.
Disciplina simples.

43. O que documentar

Não tudo.
O suficiente para governar.

Charter;
fontes;
permissões;
versão;
métricas;
incidentes;
mudanças.
Documentação deve apoiar operação.
Não existir para si própria.

44. O primeiro sucesso pode ser pequeno

Talvez o primeiro agente apenas prepare um briefing.
E poupe 25 minutos por dia.
Isso pode parecer modesto.
Mas ensina:

integração;
dados;
confiança;
responsável;
observabilidade.
Uma transformação grande pode começar com uma capacidade pequena e bem operada.

45. O primeiro fracasso também pode ser valioso

Talvez o agente não produza valor.
Descobrimos:

dados ruins;
processo desnecessário;
volume baixo;
risco alto.
Se descobrimos em 30 dias e baixo custo, foi uma boa experiência de gestão.

46. Escalar apenas aquilo que sobrevive à realidade

Demos impressionam.
Produção ensina.
O sistema precisa sobreviver:

segunda-feira;
pico;
férias;
dado errado;
cliente difícil;
API fora;
mudança de política.
Só então merece escala.

47. Os primeiros cinco artefactos

Se o leitor não fizer mais nada, pode criar amanhã:

1. Opportunity Map

Onde existe valor?

2. Process Reality Map

Como acontece hoje?

3. Result Map

O que deve mudar?

4. Agent Charter

Que capacidade construiremos?

5. Value Realization Map

Valeu a pena?
Estes cinco artefactos já mudam a qualidade da conversa.

48. Uma agenda de 90 minutos para começar

0–15 min

Escolher processo.

15–35 min

Mapear realidade.

35–50 min

Identificar perda.

50–65 min

Desenhar capacidade.

65–80 min

Definir métrica e risco.

80–90 min

responsável + próximos 30 dias.
Uma empresa pode começar sem workshop de três dias.

49. A pergunta final do diagnóstico

No fim da sessão, perguntar:

“Se este processo funcionasse perfeitamente, o que mudaria para a empresa?”

Se ninguém consegue responder, não construir ainda.
Se resposta é clara, temos direção.

A EQUAÇÃO

O primeiro sprint precisa de alterar pelo menos uma variável.

RECEITA ↑

Oportunidade capturada ou protegida.

CUSTOS ↓

Trabalho, desperdício ou custo evitado.

VELOCIDADE ↑

Latência reduzida.

CONTROLO ↑

Visibilidade, consistência ou governação.
E precisa provar que a mudança vale o custo.

50. O ponto de partida real

Não é IA.
Não é agente.
Não é modelo.
É uma frase:

“Aqui estamos a perder valor.”

Depois:

“Aqui está a capacidade que precisamos.”

Depois:

“Aqui está como vamos testar.”

É assim que tecnologia deixa de ser promessa e começa a tornar-se operação.
E é também onde terminamos a parte prática deste livro.
Resta regressar à liderança.
Porque, depois de agentes, frameworks, métricas e processos, a Empresa Aumentada continua a precisar de alguém que defina o horizonte.