Como o FARO avalia a adoção de automação

Como é feito

1. Contexto (B0). Setor, tamanho das equipes, ferramentas atuais, objetivos. Não pontua — calibra a leitura das demais respostas.
2. 23 perguntas de maturidade (B1). Cada uma sonda uma dimensão (padronização, colaboração, governança, medição de valor, autonomia). As respostas viram uma pontuação que mapeia a um dos 5 estágios.
3. 10 perguntas complementares (B2a). Aprofundam aspectos estratégicos (patrocínio executivo, reuso, comunidades de prática) que qualificam o nível.
4. Cálculo do nível (1–5). Agrega B1 (ponderado por B2a) e posiciona num estágio, com o retrato daquele estágio e as atividades-chave para avançar.

Os 5 estágios

Por que assim: automação madura não é "ter uma ferramenta" — é ter padrão, reuso, governança e valor medido disseminados. Um modelo de estágios evita tratar todos igual: quem começa precisa de padronização; quem é avançado precisa de otimização e escala. O nível também alinha expectativas (não se pede orquestração de processos a quem ainda não padronizou tarefas).

Como é feito

1. Inventariar os casos candidatos (ex.: patching, provisionamento de VM, coleta de conformidade).
2. Pontuar Complexidade: os seis fatores de construção, respondidos pelo especialista de domínio e pelo arquiteto — nº de sistemas que a tarefa toca; se existe módulo certified ou se vira comando cru; dependência de ordem/estado; exceções por modelo/versão; a interface (API, CLI/SSH ou UI/scraping); e quanta lógica condicional. Não entram aqui a reversibilidade (é Risco) nem a senioridade de quem vai construir — a régua mede a tarefa, não a equipe.
3. Pontuar Risco: a reversibilidade da operação — somente leitura · reversível com janela · irreversível —, modificada pela confiabilidade do --check quando a operação altera estado (parcial soma +1, sem --check confiável soma +2, teto 5; em somente leitura não soma nada). Impacto de falha e exposição do serviço não entram aqui: isso é a Criticidade, nota do cliente, e ela entra na Bolha — não no Risco.
4. Combinar em ICO — MAX(Complexidade, Risco), o pior dos dois: um índice de "dificuldade de operar". Não é um eixo — os eixos do quadrante são Valor e Complexidade, e o ICO não entra em nenhuma conta do motor: é leitura de preparo.
5. Pontuar Valor: o que o negócio ganha com esta tarefa automatizada — 1 = ganho marginal; 3 = ganho perceptível na rotina da área; 5 = destrava capacidade, prazo ou conformidade que hoje não se alcança. Não pontue por frequência nem por nº de hosts: isso é o Volume, que o motor deriva do as-is e que entra multiplicado na mesma Bolha — repetir o fato aqui é contá-lo duas vezes na mesma conta.
6. Plotar no quadrante — cruzamento dos eixos Valor e Complexidade (não é multiplicação) — e ler as quatro regiões com os nomes que o motor publica: alto valor / baixa complexidade = Quick Win; alto valor / alta complexidade = Estratégico; baixo valor / baixa complexidade = Eficiência; baixo valor / alta complexidade = Reavaliar. (Esta lista trazia "oportunistas" e "evitar", que não existem no motor nem na tela — quem ouvisse aqui e olhasse o gráfico veria outros quatro nomes.)

Por que assim: recursos são finitos. Priorizar valor contra esforço entrega resultado cedo (gera patrocínio) e evita começar por um caso difícil e de pouco valor. Separar o Risco importa: um caso "fácil" tecnicamente pode ser perigoso (mexer em produção crítica). Mas o Risco não rebaixa a prioridade — ele bloqueia: não entra no Quadrante (Valor × Complexidade) nem na Bolha ((Valor × Volume × Criticidade) ÷ Complexidade), e age só no gate de onda, recusando o caso cujo Risco passe do teto do nível daquela onda (ADR-FARO-004 §5). Um Quick Win de Risco alto continua sendo Quick Win e continua com a mesma Bolha; ele apenas não abre a entrega.

Como é feito

1. Definir os domínios a investigar.
2. Coletar evidências: inventário de hosts, versões, topologia de rede (segmentação, firewalls, portas), plataformas de virtualização/nuvem, sistema operacional, latências e restrições.
3. Registrar requisitos de conectividade: portas, NTP, SSH, acesso root/sudo, PostgreSQL externo, saída para console/analytics.
4. Identificar segmentação de rede que exigirá desenho de mesh (redes isoladas → nós de salto).
5. Consolidar como insumo direto para casos de uso viáveis e para o sizing.

Por que assim: sem o retrato técnico, sizing e arquitetura são chute. O discovery revela as restrições que definem a topologia — redes segmentadas obrigam nós de salto; o banco externo tem versão suportada; NTP/SSH/portas precisam estar prontos antes de instalar. É o pilar que conecta "o que queremos automatizar" com "o que o ambiente permite".

Como é feito

1. Estimar a carga: nº de hosts, jobs simultâneos, janelas → define o número de forks (execuções em paralelo).
2. RAM: mínimo oficial de 16 GB por nó (32 GB para a growth com seed de collections). Acima do piso, dimensione pela carga de forks (heurística de capacidade ~100 MB/fork).
3. CPU: mínimo oficial de 4 vCPU por nó; acima disso acompanha a densidade de forks.
4. Escolher e contar os tipos de nó (Automation Mesh) — ver tabela abaixo.
5. PostgreSQL: versão 15 (gerenciado pelo instalador ou externo com a versão suportada pela release), com recursos próprios.
6. Validar IOPS de disco (banco e nós): alvo oficial 3000 IOPS, medido com o FIO.
7. Encaixar numa topologia testada (Growth / Enterprise) em vez de desenhar do zero.

Tipos de nó (Automation Mesh)

Variáveis que determinam o sizing

Por que assim: forks são o motor da execução paralela; se faltar RAM, os jobs falham ou ficam lentos — por isso RAM se atrela a forks, não a um valor fixo. Separar control de execution (enterprise) dá resiliência e escala independente. Hop nodes existem porque redes reais são segmentadas. IOPS via FIO importa porque um banco lento derruba tudo — "o disco parece rápido" não é evidência, a medição é. Usar uma topologia testada garante uma combinação suportada.

O que existe hoje

1. Os campos nº de hosts, duração da tarefa manual e frequência são capturados no as-is.
2. Esses mesmos fatos alimentam duas coisas: o motor deriva o Volume (hosts×frequência, ADR-FARO-010 — não é nota respondida pelo cliente) e calcula a economia de horas da carteira.
3. A priorização usa a Bolha = (Valor × Volume × Criticidade) ÷ Complexidade — oportunidade relativa ao esforço, não moeda.
4. O ROI traz a moeda: VPL, payback descontado, TIR e índice sobre valor presente, com horizonte e taxa únicos para toda a carteira; separa economia de caixa de custo evitado e publica um cenário de estresse com os fatores de optimism bias do HM Treasury.
5. Precedência, quando os índices discordam: o gate de risco bloqueia; o VPL decide; a Bolha ordena quem passou; o Quadrante comunica; o ICO é leitura de preparo.

O que ainda é roadmap: a integração com o Automation Savings Planner da Red Hat — outra peça e outro cálculo (lá é custo manual − custo automatizado, e "risk-adjusted" não existe na documentação dele). Não apresente um como se fosse o outro. Planejar (forecast) ≠ realizado (medido depois).