Escritório de Automatizações

Faro para o que vale automatizar.

Decidir o que automatizar costuma ser disputa de opinião. O FARO troca isso por uma conta que se confere — da nota de cada caso, com fator, fonte e responsável, ao retorno da carteira, com premissa de dono nomeado e um número que pode ser reexecutado depois.

Conhecer o método

Fontes gratuitas e públicas do começo ao fim: nenhuma citação que o cliente não consiga abrir.

Índice de Complexidade Operacional

ICO = MAX(Complexidade, Risco)

O pior dos dois manda. Média esconderia o risco.

Quadrante

matriz Valor × Complexidade

Cruzamento de eixos, não multiplicação.

Oportunidade · tamanho da bolha

(Valor × Volume × Criticidade) ÷ Complexidade

Retorno pelo esforço, em escala fixa: filtrar não muda bolha nenhuma.

O problema

De tudo que dá para automatizar, o que fazer primeiro — e compensa?

Duas perguntas que costumam ser respondidas por quem fala mais alto. O FARO responde as duas com números que têm origem, e deixa o caminho aberto para alguém conferir.

Como cada pergunta costuma ser respondida, e como o FARO responde
Na hora de decidir Como costuma ser respondido Como o FARO responde
De onde vem a nota De uma reunião. Ninguém consegue reconstruir depois por que aquele caso tirou 4 e não 2. Propriedades técnicas verificáveis, na mesma régua para todos os domínios. De qualquer nota se abre fator → âncora → fonte → quem respondeu.fator · âncora · fonte · RACI
Se compensa Uma economia estimada no slide, sem dono e sem data de validade. VPL, payback descontado, ROI e SIR sobre a carteira — e cada premissa com quem responde por ela, de onde veio e até quando revisar.NIST HB 135 · HM Treasury Green Book
Seis meses depois O número virou folclore. Ninguém sabe se ainda vale. O número que foi à decisão é congelado com insumos, réguas e hash. O produto reexecuta e diz se ainda bate — ou se a régua mudou.régua vN · hash de insumos · data

Passo 6 · antes de qualquer número

Primeiro descreva o trabalho como ele é hoje

O método não começa perguntando se o caso é bom. Começa pedindo a rotina manual: quem dispara, que passos, em quais sistemas, quanto tempo. É o insumo mais barato do FARO — cerca de cinco minutos por caso — e o único sem o qual nada mais roda.

como é feito à mão hoje

A rotina que se quer automatizar, passo a passo — e o sistema de cada passo

Exemplo real do acervo: MF-01 · Backup do running-config dos switches, domínio Rede. Gatilho: agendamento recorrente. Sem aprovação — é operação de leitura. Executa: Rede crítica.

passo 1

Abrir sessão SSH no switch a partir do jump server

jump-bh-01 / jump-bh-02

passo 2

Executar show running-config e copiar a saída

Switch (IOS-XE / IOS / NX-OS)

passo 3

Colar o conteúdo em arquivo nomeado por hostname e data

Estação do analista

passo 4

Depositar o arquivo no repositório de configurações

GitLab CE (automacao/)

passo 5

Conferir por amostragem se a coleta saiu para todos os sites

Planilha de controle

O bloco acima é a rotina de um switch. Ela se repete 229 vezes por campanha — e a campanha é mensal. Duas decisões humanas no meio: se o device está em planta (zona OT) → passar pelo jump da planta; se a sessão cai → repetir até 3 vezes antes de abrir chamado.

alvos no parque

229

switches, inventário fechado por modelo

ainda feitos à mão

143

86 já cobertos por um script Expect; o benefício conta só os 143

tempo manual

21 min

por switch, por campanha

trabalho manual por ano

600,6 h

143 × 21 min × 12 campanhas

E o que a rotina de hoje não tem. Da própria descrição do as-is: “Device inacessível na campanha: fica sem backup do mês e ninguém é avisado — descoberto só na conferência por amostragem.” A falha existe, é conhecida, e o processo manual só a encontra depois, se encontrar.

É este bloco que o método pede antes de qualquer nota. Ele não é burocracia: é de onde saem o Volume (229 × 12 = 2.748 execuções/ano → nota 4 de 5), as horas que a automação pode poupar, e a lista de sistemas que o discovery vai procurar na documentação oficial.

Passos, sistemas, pontos de decisão e exceções são o texto literal do as-is do MF-01 na carteira de demonstração. As 600,6 h/ano saem da linha de base corrigida — 229 do parque menos 86 já cobertos — e é essa a base que entra no cálculo econômico. fonte: minasforte-dataset.json · MF-01 · operacao.passos, operacao.decisoes, operacao.excecoes, savings.hosts=143, tempo_manual_min=21, freq 1×mês

detalhar um caso de uso

Descrever como o trabalho é feito hoje — 22 campos, e três números que o motor lê

Não é um formulário de notas. É o gatilho da demanda, o passo a passo com o sistema de cada etapa, quem executa, quem aprova, o que costuma dar errado. Leva cerca de 5 minutos por caso, e a gaveta salva sozinha enquanto você digita.

Gaveta “Como é feito hoje (as-is)”7 blocos · 22 campos

  1. 1 · de onde vem a demanda

    Gatilho da demanda · Tipo da demanda (ITIL) · Pré-condições

  2. 2 · como é feito hoje

    Passo a passo do processo manual — um passo por item: a ação e em qual sistema · Sistemas e integrações tocados · Pontos de decisão e aprovação · Exceções, e o que se faz quando dá errado

  3. 3 · entradas e saídas (SIPOC)

    Entradas necessárias · Saídas e resultado · Consumidor do resultado

  4. 4 · quem faz (RACI)

    Quem executa · Quem aprova / autoriza · Consultados e informados

  5. 5 · restrições e riscos

    Janela / restrição temporal · Regras de negócio e política · Depende de (outros casos) · Risco e impacto se falhar — o fato; a nota de Criticidade é do cliente, em outra tela · Variabilidade e % de exceções

  6. 6 · quanto — alimenta o Volume derivado

    Frequência · Tempo manual por execução (min) · Nº de alvos/hosts por execução

  7. 7 · conclusão

    Critério de sucesso / validação — como se sabe, hoje, que a operação terminou com êxito

  1. 229alvos por execução

    Quantos servidores ou devices o processo toca de uma vez. No exemplo: os switches do parque.

  2. 1 × mêsfrequência

    Com que regularidade a demanda ocorre. O vocabulário de período é fechado — dia · semana · quinzena · mês · bimestre · trimestre · semestre · ano.

  3. 21 mintempo manual por execução

    Duração típica de mão de obra por alvo. É a única porta de entrada do benefício.

Com os três, o motor deriva sozinho:
Volume = hosts × frequência × vezes por ano = 229 × 1 × 12 = 2.748 execuções/ano → nota 4 de 5.
E o benefício ganha um número de horas para poupar. Sem eles, nada disso existe.

E o que ele se recusa a fazer. Falta um dos três e o caso não vira nota redonda: aparece com o diagnóstico do campo que falta — hosts_ausente, frequencia_ausente, tempo_manual_ausente. E recusa "1.000", que é mil em português e um em inglês: o produto não escolhe por você.

Os 22 campos são os da gaveta do produto, na ordem em que ela os pede. Os três números do exemplo são os do caso MF-01 da carteira de demonstração. Nessa carteira, 23 dos 29 casos (79%) têm o as-is completo — e o produto diz, caso a caso, qual campo falta nos outros seis. fonte: index.html · OPSPEC · faro_engine.py · volume_derivado, PER_ANO, VOL_FAIXAS, MOTIVOS_VOLUME · ADR-FARO-006, ADR-FARO-010

Passo 7 · a régua de classificação

A nota não é opinião convertida em número

Oito perguntas de fato, com dono declarado e resposta em texto — nunca em nota. O motor faz a conta; ninguém digita o resultado. Aqui está a régua inteira, e o que ela faz com cada resposta.

a régua de classificação

Oito perguntas de fato, dois donos, uma nota que ninguém digita

Nenhuma delas pergunta se o caso é complexo, e nenhuma pede uma nota de 1 a 5. Todas perguntam uma propriedade do artefato de automação — e a resposta é uma âncora escrita, não um número.

quem responde o quê

Especialista de domínio

Q1 · Q3 · Q5 · Q6 · Q8

Fato de domínio: quantos sistemas a tarefa toca, se a ordem dos passos importa, quantas variações por modelo e versão existem, por qual interface se fala com o sistema, quanta decisão o playbook precisa tomar.

Arquiteto de automação

Q2 · Q4 · Q7

Fato de plataforma: existe módulo pronto e de qual tier, a operação é reversível, o --check é confiável. São as três que o arquiteto responde igual em qualquer domínio.

Cliente — e o que ninguém responde

Valor · Criticidade · Volume

Valor e Criticidade são do lado do cliente, e o dono sai de uma lista fechada de quatro papéis: dono do serviço, gestor de negócio, patrocinador, controladoria. Volume não se pergunta a ninguém — é derivado do as-is.

as oito questões, e as âncoras de cada uma

  1. Q1

    Complexidadeespecialista

    Quantos sistemas/plataformas a automatização toca?

    1 sistema→2–3→4 ou mais

  2. Q2

    Complexidadearquiteto

    Existe módulo Ansible pronto para a tarefa?

    Sim, certified/supported→Só community→Não — comando cru / script

  3. Q3

    Complexidadeespecialista

    A ordem dos passos importa / precisa gerenciar estado?

    Não→Um pouco→Muito

  4. Q4

    Riscoarquiteto

    A operação é reversível?

    Somente leitura→Reversível com janela→Irreversível

  5. Q5

    Complexidadeespecialista

    Quantas exceções por modelo/versão/plataforma?

    Poucas→Algumas→Muitas

  6. Q6

    Complexidadeespecialista

    Interface principal da tarefa?

    API REST→CLI / SSH→UI / scraping

  7. Q7

    Modificador de Riscoarquiteto

    O dry-run (--check) é confiável?

    Sim→Parcial→Não

  8. Q8

    Complexidadeespecialista

    Quanta lógica / decisão condicional?

    Pouca→Média→Muita

Nenhuma das oito fala de rede, de Linux ou de banco. Todas falam de módulo pronto, interface, ordem de execução e variação de plataforma — propriedades do artefato, não do assunto. É por isso que a mesma régua serve para todos os domínios, e por isso a discordância desce para um fato: são mesmo três sistemas? o módulo é mesmo certified?

o que a máquina faz com as âncoras

Complexidade — seis fatores

soma as âncoras de Q1 Q2 Q3 Q5 Q6 Q8
→ converte em faixa pelos cortes 1 · 3 · 6 · 9

123 45 13 69

← soma dos fatoresacima de 9 →

O que é IP e o que não é. O peso de cada âncora não é publicado. Os cortes — 1, 3, 6, 9 — são. E a régua inteira, pesos inclusive, entra no hash do carimbo: você não vê o peso, mas nenhuma mudança nele passa despercebida.

  1. Regra de piso. Módulo certified, um único sistema e operação somente leitura — e o acumulado dentro do teto da regra: a Complexidade cai para 1. Se o gatilho está presente mas os outros fatores elevam o esforço, a tela diz que a regra não foi aplicada, e por quê.
  2. Regra de interface. Se o caso só se resolve por tela e a Complexidade está abaixo de 4, ela sobe para 4. Automação por tela quebra a cada mudança de layout.
  3. A ordem entre as duas não é detalhe: o piso roda primeiro e a interface prevalece. Em 12 das 6.561 combinações possíveis, essa ordem dá nota 4 — e a ordem invertida daria 1. Existe teste que percorre as 6.561 e falha se a ordem mudar.

Risco — dois fatores, e um teto

risco = mín(5, âncora de Q4 + âncora de Q7)
→ o modificador de dry-run só entra quando a operação altera estado

Ser somente leitura reduz o Risco, não a Complexidade: se nada é alterado, não há mudança falha a descobrir — a resposta de dry-run fica registrada e não move a nota. Coletar dado de muitos modelos e versões continua sendo esforço de engenharia.

Uma consequência declarada, não maquiada. Com o gatilho e o teto acima, a nota 2 de Risco é inalcançável nesta régua. Não é defeito — é o que a régua produz, e o produto documenta em vez de esconder.

E os dois viram um índice

ICO = MAX(Complexidade, Risco)
[1–2] Baixo · [3] Médio · [4–5] Alto

Máximo, não média. Um caso simples de executar mas arriscado não é um caso médio — é um caso arriscado. E é o Risco, não o ICO, que o gate de onda consulta na hora de liberar a entrega.

Régua vigente faro-1.3. O texto das oito questões e das âncoras é o do próprio motor; os pesos por âncora são propriedade intelectual e não aparecem aqui, nem na API. fonte: faro_engine.py · FATORES, CX_FAIXAS_CORTES, PISO_CX_ALVO, UI_CX_ALVO, RISCO_TETO · ADR-FARO-007, ADR-FARO-008 · docs/metodo/02-classificar-a-nota.md

a tese, posta à prova

Rede não é mais difícil que Linux. O caminho é que decide.

A objeção mais comum a qualquer régua é “quem disse que o meu domínio é mais complexo que o seu?”. A resposta do FARO não é um argumento — são dois casos da mesma carteira, com o mesmo valor para o negócio, e a conta aberta de por que a nota diverge.

um caso de rede, um caso de linux

Mesmo valor para o negócio, mesma complexidade, mesma posição na fila — e notas diferentes

Dois casos reais da mesma carteira. O cliente deu a mesma nota de Valor e de Criticidade aos dois, e o motor derivou o mesmo Volume. Seis das oito âncoras técnicas são idênticas. Ainda assim, um entra na primeira onda e o outro só na terceira.

MF-01 · Rede

Backup do running-config dos switches

229 switches, campanha mensal. Módulo cisco.ios.ios_command, tier certified. Operação estritamente somente leitura.

MF-02 · Linux & Plataforma

Ciclo de patches em servidores RHEL

370 hosts RHEL (7, 8 e 9), ciclo mensal na janela de sábado. Módulo ansible.builtin.dnf, tier supported. Altera estado e reinicia o host.

Valor para o negócio

5 = 5

o cliente respondeu a mesma coisa nos dois

Criticidade

5 = 5

produção com SLA / segurança, nos dois

Volume — derivado, não perguntado

4 = 4

229 × 12 = 2.748 e 370 × 12 = 4.440: mesma faixa (2.000–10.000)

as oito âncoras — o que cada um respondeu
questão da régua MF-01 · Rede MF-02 · Linux
Q1 Quantos sistemas a automatização toca?2–32–3
Q2 Existe módulo Ansible pronto?Sim, certified/supportedSim, certified/supported
Q3 A ordem dos passos importa?NãoUm pouco
Q4 A operação é reversível?Somente leituraReversível com janela
Q5 Exceções por modelo/versão?MuitasMuitas
Q6 Interface principal da tarefaCLI / SSHCLI / SSH
Q7 O dry-run é confiável?SimParcial
Q8 Quanta lógica condicional?MédiaMédia

Onde os dois divergem, e onde não. A única divergência de Complexidade é a Q3, e ela não é suficiente para atravessar o corte 6: as duas somas caem na mesma faixa, e a Complexidade dos dois é 3. As outras duas divergências, Q4 e Q7, não entram na Complexidade — entram no Risco.

o que a régua devolveu

MF-01 · Rede

  • Complexidade3 / 5
  • Risco1 / 5
  • ICO = MAX(3, 1)3 · Médio
  • QuadranteQuick Win
  • Oportunidade (bolha)33,3

Gate de risco por onda. Onda 1 — Fundação, tier read-only, teto de risco 2: cabe. É o primeiro caso a entrar.

MF-02 · Linux

  • Complexidade3 / 5
  • Risco — salto por dry-run parcial3 → 4 / 5
  • ICO = MAX(3, 4)4 · Alto
  • QuadranteQuick Win
  • Oportunidade (bolha)33,3

Gate de risco por onda. Onda 1 read-only, teto 2: não cabe. Onda 2 reversível, teto 3: não cabe. Onda 3 — Mudança em produção, teto 5: cabe.

Os dois casos empatam na fila — mesma Oportunidade, 33,3 — e mesmo assim são entregues em ondas diferentes. O que os separou não foi rede nem Linux: foi reversibilidade e confiança do dry-run. Um só lê, e não tem o que desfazer. O outro muda produção, reinicia o host, e a simulação do módulo cobre parte das tarefas — uma simulação incompleta dá confiança falsa: o erro aparece na aplicação. Nenhuma dessas duas perguntas é sobre o assunto. A dificuldade é do caminho, não do domínio.

Todos os números saem da carteira de demonstração e da régua faro-1.3, reexecutados no motor. O salto de Risco 3 → 4 do MF-02 é a regra de dry-run parcial sobre operação que altera estado; o MF-01 responde a mesma pergunta e a nota não se move, porque em somente leitura não há mudança falha a descobrir. fonte: minasforte-dataset.json · MF-01, MF-02 · faro_engine.py · classify, risco_cabe_na_onda, RISCO_MAX_POR_TIER, BOLHA_FORMULA · ADR-FARO-004 §5, ADR-FARO-008

Veja funcionando

O FARO, do problema à decisão

Nove minutos percorrendo cada quadro com calma — nenhuma captura de tela, porque tela não explica método. O que o instrumento faz, o que ele se recusa a fazer, e por que o número que ele emite resiste à segunda pergunta.

ilustração autoral· voz sintética· 9 min 16 s

  1. o problema — por que candidato sobra e ordem falta
  2. as duas perguntas, e por que uma não substitui a outra
  3. a promessa: cada número com origem, dono e fonte que abre
  4. o que o FARO não faz
  5. quanto trabalho isto dá com os seus casos
49demonstrações gravadas
3h30de tela real
100%das fontes públicas e abríveis
Abrir a documentação →

A documentação abre em metodo.html, com carregamento sob clique — nada baixa antes de você pedir.

O método

Três momentos, nove passos

Compõe frameworks consagrados num trilho único — PMI, TOGAF, ITIL 4, DORA e Red Hat na classificação; NIST Handbook 135 e HM Treasury Green Book na conta econômica. Cada peça entra no passo em que tem autoridade.

  1. o método completo

    I

    Inventariar

    Descobrir e catalogar os casos de uso.

    1. Estratégia e governança. Patrocínio e CoE/CoP antes de classificar.
    2. Descoberta. Levantar candidatos com ID, domínio e descrição.

  2. medir de forma defensável

    A

    Avaliar

    Classificar por números de fonte confiável.

    1. Coleta de fatos (RACI). Fato técnico ≠ fato de negócio.
    2. Régua 1–5 por fatores objetivos. Com âncoras de referência.
    3. Índices derivados. ICO, Quadrante e Bolha — nada digitado à mão.

  3. priorizar, planejar e entregar

    O

    Orquestrar

    Priorizar, validar e entregar o que vale.

    1. Priorização e ondas. Quem governa a onda é o gate de risco.
    2. Validação com o cliente. Valor e Criticidade confirmados.
    3. Conteúdo Red Hat-first. Collection oficial, certified → validated.
    4. Governança e evidências. ADR, C4, DORA e ITIL 4.

Comece pelo que você já tem

Traga cinco casos. A primeira nota sai na mesma reunião.

Sem planilha nova, sem levantamento de três meses. Você classifica os cinco na régua do produto e sai com o quadrante, o ICO e a origem de cada número — o suficiente para a segunda reunião ser sobre a ordem, e não sobre a opinião.

Conhecer o método

Início

Faro para o que vale automatizar.
—
A carteira deste cliente (ao vivo)a carteira é o conjunto de casos que entram na conta econômica juntos — a subscrição da plataforma entra nela uma vez, não em cada caso
Evolução — implementação e governança
Onde investir primeiro

Priorização — matriz Valor × Complexidade (cruzamento de eixos, não multiplicação)

Tamanho da bolha = a Oportunidade (o retorno pelo esforço), numa escala fixa — filtrar não muda o tamanho de nenhuma bolha. O tamanho ordena, não mede: o raio tem um piso para o caso pequeno não sumir da tela, e por isso o dobro de área não vale o dobro. Este gráfico é menor que o da Priorização e desenha o mesmo caso menor em pixels, na mesma proporção da própria faixa de raio; lá estão a legenda completa e os números para comparar.

Distribuição por ICO

Caminho até o sizing

Este painel mostra o estado deste cliente. Para entender o método — o que o FARO resolve, o que você recebe e quem preenche o quê — veja .

Assistente

Pergunte em linguagem natural. Respondo primeiro pela documentação oficial indexada (citando a fonte); se não constar, busco na web e marco a origem. Nunca misturo as duas.

Casos de uso

Todos os casos de uso. Classifique, vincule a um projeto (um UC fica em no máximo um projeto) ou desvincule para devolver ao backlog.
A ordem da lista é a fila recomendada do método: por Quadrante — Quick Win, Estratégico, Eficiência, Reavaliar — e, dentro de cada um, pela Oportunidade, da maior para a menor. No empate valem, nesta ordem, Risco menor, Complexidade menor e Valor maior — é esse critério que o selo “empate em … · desempatado por …” nomeia na linha, caso a caso. Quando nenhum dos três separa um caso do vizinho imediato, o selo diz “código (determinismo, não método)”: a ordem entre os dois é a alfabética, só para a lista não dançar entre dois desenhos — e não é prioridade. Casos ainda não classificados ficam depois dos quatro quadrantes, e os de nota de negócio assumida pelo motor ficam por último: a posição deles saiu de um número que ninguém respondeu. E ordenar não é entregar — quem libera a entrega é o gate de risco da onda. Como a nota é calculada ↗

com contexto técnico → pesquisa de documentação/collection oficial anexada
Filtrar
IDCaso de usoDomínioICOEstadoProjetoAções

Projetos

Cada projeto organiza seus casos de uso em ondas e cronograma próprios.

CódigoProjetoUCsEstadoAções

—

Casos de uso do projeto

IDCasoICOOndaAções

Ondas

Cronograma

Classificar

O especialista responde os fatos; o motor calcula. Cada questão mostra quem responde (RACI) e um help.

RACI — quem responde o quê (clique para abrir)

R Responsável (faz/responde) · A Aprova · C Consultado · I Informado.

EtapaEspecialista de domínioArquitetoLead do projetoCliente / Negócio
Descrever o UC + contexto técnicoRCIC
Fatos técnicos (8 fatores → Complexidade/Risco)RAI—
Notas de negócio (Valor / Criticidade) — Volume é derivado de hosts×frequênciaCCCR
Índices ICO / Quadrante / Bolha (automático)IIII
Validar a classificaçãoCARC
Priorizar / alocar em ondaCARC

Regra do método: fato técnico é do especialista/arquiteto; nota de negócio é do cliente — ninguém opina fora da sua competência.

—

Resultado (automático)

Negócio (cliente):

Retorno do investimento

Quanto a automação deixa de gastar, quanto custa construir e manter, e se o caso se paga — com a conta aberta passo a passo, cada premissa marcada como medida ou presumida.

Carregando…

Carimbos emitidos — passo 20

Cada carimbo congela os insumos, o resultado e as duas réguas — a de classificação e a econômica. Conferir reexecuta o cálculo a partir do que ficou congelado e devolve um veredito, não um "ok". São seis: íntegro · régua mudou (o número continua certo para a régua da época e deixou de ser comparável) · não reproduz · linha adulterada (o digest não bate — alteraram fora do produto) · entrada não registrada (o carimbo não guardou os insumos: dá para comparar o resultado, não para reexecutar) · sem digest (carimbo anterior ao digest). Um número emitido não se reescreve.

—

Priorização

Cada caso classificado é uma bolha: a posição é o cruzamento dos eixos Valor e Complexidade (cruzamento de eixos, não multiplicação) e o tamanho é a Oportunidade numa escala fixa, a mesma em todas as telas — filtrar não muda o tamanho de nenhuma bolha. A legenda abaixo do gráfico abre a codificação inteira, e a tabela logo abaixo traz os mesmos casos em texto. Filtre por projeto para focar; acompanhe todos os projetos do cliente.

Projeto

Matriz de priorização

Passe o cursor sobre uma bolha para ver a conta. Pelo teclado: Tab chega ao gráfico e as setas percorrem os casos em ordem de Oportunidade (Esc fecha).

Casos no gráfico — os mesmos números, em texto

Espelha o filtro de projeto acima e lista exatamente os casos desenhados.
Casos de uso desenhados na matriz de priorização, com Valor, Complexidade, Oportunidade, VPL, Quadrante, Estado, Onda e notas assumidas — a alternativa textual do gráfico. A coluna VPL não é canal do desenho: é o valor presente líquido que a tela de Retorno do investimento calcula para o mesmo caso, trazido para cá porque as duas ordens discordam.
CódigoCaso de usoDomínio ValorComplexidade VolumeCriticidade VPL (valor presente líquido, da tela de Retorno do investimento; SIR na linha de baixo) QuadranteRiscoICO EstadoOnda Notas assumidasProjeto

Ondas do projeto

Doc-lookup

Procedimento e módulo/collection com a fonte citada — dentro do acervo declarado abaixo. Fora dele, esta tela diz que está fora, em vez de devolver o documento mais próximo.

🤖 IA generativa da busca (opcional · resume os trechos oficiais em procedimento, sempre citando a fonte)
📚 Base de conhecimento — fontes oficiais (envie PDF, URL ou texto; a busca cita a fonte)

Apresentação ao cliente

Modo apresentador (até 3 telas, sincronizadas): a Tela do cliente vai para o projetor; a Tela do apresentador mostra o que dizer com suas palavras, os pontos, o próximo slide, o cronômetro; e a Ajuda & Glossário (ao seu lado, ou num tablet) traz os termos deste slide + a busca de qualquer termo que o cliente questionar. As três se sincronizam — você navega em qualquer uma e as outras acompanham (mesmo navegador). Atalhos: setas navegam · G/Ctrl+K busca · F tela cheia · N notas.

🎨 Marca da apresentação — logos do parceiro e do cliente (co-branding)
Esta página é referência geral — ela não conhece o seu sizing.
A lista que vale para um ambiente concreto é gerada dos parâmetros dele (topologia, plataforma, instalação online ou bundled) e aparece em Sizing AAP › Pré-requisitos que o BoM assume, com a citação da doc oficial em cada item. Onde as duas divergirem, a dinâmica é a correta.

Documentação

O caminho completo do FARO — da preparação e do assessment ao sizing dimensionado e à decisão econômica. Siga na ordem; cada passo diz onde fica no menu (clique no marcador para ir direto).

O que o FARO resolve

Decide o que vale automatizar — com nota, fonte e responsável — e entrega um plano de adoção pronto.

Acaba com o achismo: transforma a lista de "o que automatizar" em prioridade (quadrante e ondas), tamanho (sizing AAP 2.7) e retorno (VPL da carteira, com o que foi descartado e por quê) — cada decisão rastreável até a fonte oficial, cada premissa econômica com dono nomeado, e o número da reunião congelado num registro que o produto reexecuta.

📦 O que você recebe (o resultado)

São 6 entregas — 4 saem direto dos 9 passos; Discovery e Sizing apoiam pelo assessment:

🙋 Quem preenche o quê — e para quê

PapelPreenchePara quê
Especialista de domínioComplexidade (fatos técnicos)medir o esforço real
Arquiteto de AutomaçãoRisco · módulo pronto · decisõesavaliar reversibilidade e viabilidade
Cliente / NegócioValor · Criticidadedizer o quanto importa ao negócio
FARO (automático)Volume (derivado de hosts×frequência) · ICO · Quadrante · Sizingcalcular sem viés, citando a fonte
Fase 0 · Preparar o terreno
1

Cadastrar o cliente

Registrar o cliente (tenant) que será avaliado — código, nome e segmento.

Clientes ↗
2

Cadastrar a equipe

Registrar os colaboradores do projeto (engenheiros, especialistas de domínio, arquitetos, tech leads, gerentes) com papel e domínios. Alimenta o RACI e os squads.

Equipe ↗
3

Criar os projetos

Cada projeto organiza seus casos de uso em ondas e cronograma próprios.

Projetos ↗
4

Designar os squads

Cada projeto tem um squad designado; os membros vêm da Equipe (um colaborador pode estar em vários squads).

Squads ↗
Fase 1 · Avaliar (diagnóstico)
5

Medir a maturidade

Responder o pilar de Estratégia & Maturidade (contexto + 23 perguntas que calculam o nível 1–5 + 10 complementares). Cada pergunta tem ajuda e responsável.

Assessment › Estratégia & Maturidade ↗
6

Levantar os casos de uso

Cadastrar (ou importar) os casos candidatos — descrição + contexto técnico (equipamentos, software, versões).

Casos de uso ↗
7

Classificar cada caso

Fatos técnicos (especialista + arquiteto) → Complexidade e Risco; notas de negócio (cliente) → Valor e Criticidade. O Volume é derivado de hosts×frequência do as-is. O ICO, o Quadrante e a Bolha calculam sozinhos.

Classificar ↗
8

Discovery técnico por domínio

Coletar evidências do ambiente real por domínio (versões, topologia de rede, restrições) — insumo para viabilidade e sizing.

Assessment › Discovery técnico ↗
Fase 2 · Priorizar (decidir)
9

Ler a priorização

O gráfico de bolhas mostra o que entrega mais oportunidade pelo esforço, entre os candidatos. Mais à esquerda e mais alto = melhor. Não é o cronograma: a onda vem no passo seguinte, e quem a governa é o gate de risco.

Priorização ↗
10

Organizar em ondas

Vincular os casos ao projeto e alocá-los em ondas, faseando por risco: o método recomenda abrir com uma onda read-only (ADR-FARO-004 §5), mas o nível de cada onda é decisão do plano do projeto — o gate compara o Risco do caso com o teto do nível daquela onda e recusa quem passa, seja ele Quick Win ou não.

Projetos › Ondas ↗
Fase 3 · Dimensionar (entregar)
11

Fundamentar com a doc oficial

Ingerir a documentação oficial (PDFs, em lote) na Base de conhecimento e consultar procedimentos/collections — tudo citando a fonte.

Doc-lookup ↗
12

Dimensionar a plataforma

Calcular a AAP 2.7 a partir da topologia testada pela Red Hat: nós de controle, execução e hop, RAM, CPU, PostgreSQL e IOPS. Onde a documentação do fabricante se contradiz, o motor roda as duas leituras e mostra as duas — não escolhe uma em silêncio.

Sizing AAP ↗
13

Salvar o ambiente e conferir o alcance de rede

O ambiente salvo guarda o BoM por VM e, em cada uma, a zona de rede. Com isso o sistema responde a pergunta que só aparece na implantação: os alvos são alcançáveis? Conta as fronteiras de firewall atravessadas e declara o que não conseguiu concluir.

Ambientes ↗
14

Checar os pré-requisitos

O que precisa existir antes de instalar: versão de SO, banco, storage, balanceador, liberações. Entrada bloqueante sem resposta impede a emissão — o sizing sai como “PARCIAL — NÃO CONTRATÁVEL”, dizendo o que destrava.

Pré-requisitos ↗
Fase 4 · Decidir (o dinheiro)
15

Cadastrar a base econômica

O valor da hora do cliente, versionado por data (o dissídio muda, o número de março continua recalculável), e as premissas com dono. Premissa sem dono não é erro do sistema: é a informação mais útil da tela, porque é sempre por ela que o cliente pergunta.

Base econômica ↗
16

Cadastrar a subscrição do AAP

O contrato por trás do custo de plataforma: nós contratados, vigência, valor e comprovante. Substitui um número digitado. Termo publicado é imutável — renovar cria registro novo apontando o anterior.

Base econômica › Subscrições ↗
17

Validar as notas com o cliente

O dono do serviço confirma Valor e Criticidade. Fica registrado quem confirmou, quando e em que reunião — separado de quem registrou. Sem isso o número segue como rascunho interno.

Casos de uso › Validar ↗
18

Ler o ROI da carteira

VPL, payback descontado, retorno sobre o PV de todos os custos e os dois índices por real — por real de CAPEX e por real de custo total —, com o SIR de cada caso na tabela da carteira. Tudo sobre valor presente, com horizonte e taxa únicos para toda a carteira. Separa economia de caixa de custo evitado, e mostra o cenário de estresse com os fatores oficiais do HM Treasury. TIR e AIRR o motor calcula e o carimbo congela, mas a tela não publica — a TIR porque a OMB A-94 é literal, “the internal rate of return does not generally provide an acceptable decision criterion”; o AIRR porque a taxa de reinvestimento que a Eq. 6-6 do NIST HB 135 exige é hoje, por premissa nossa, a própria taxa de desconto — e premissa que não é declarada não vira número na tela.

ROI ↗
19

Decidir o que NÃO fazer

Caso que não se paga sai da carteira sem perder a avaliação: motivo de vocabulário fechado, decisor nomeado e data. E o sistema calcula quanto o caso precisaria valer em benefício não financeiro para se justificar mesmo assim — quem assume esse valor é uma pessoa, não o modelo.

Casos de uso › Rejeitar ↗
20

Congelar o número e emitir

O snapshot registra o resultado com autor, data, régua da época e quem estava rejeitado — dois relatórios com a mesma régua podem divergir só por decisão de escopo. E ele não só congela: a reprodução reexecuta os insumos e diz se o hash confere e se as réguas ainda são as da emissão. Daí saem a planilha (assessment, BoM e rastreabilidade) e o HLD em PDF.

ROI › Snapshots ↗
🏁 Resultado: ao fim das quatro fases de trabalho — a Fase 0 é preparação, não entrega — você tem o nível de maturidade, os casos classificados, validados pelo cliente e priorizados em ondas, o discovery do ambiente, o sizing dimensionado e com alcance de rede conferido, o ROI da carteira com as decisões de escopo registradas, e os entregáveis — planilha e HLD. O que o FARO garante não é o número: é que cada número tem origem verificável, que toda premissa tem dono e data, e que a ferramenta se recusa a emitir o que ainda não sabe.

Quer entender por que cada passo é assim e de onde vem o método? Veja Método (a classificação) e Guia do Assessment (os 4 pilares, fundamentados).

Régua (administração)

Editar as questões, dimensão e quem responde. Publicar versiona a régua — os pesos ficam no servidor (IP).

Questões

#
PERGUNTA
DIMENSÃO
RESPONDENTE

Clientes

Registro dos clientes (tenants). Cada cliente tem seu próprio espaço isolado; aqui você cadastra o código, o nome e o segmento.

CódigoNomeTenantSegmentoEstadoDadosAções

Base econômica

O valor da hora de cada tipo de profissional e o dono de cada premissa do cálculo de ROI. É daqui que sai todo número em reais que o FARO apresenta — sem isto, o motor usa a referência do método e marca o resultado como presumido.

Tabela de custo-hora

Cada versão vale a partir de uma data. Quando o dissídio muda o valor, você cria uma versão nova — a anterior não é apagada, fecha na véspera da nova. Assim um caso de março continua sendo recalculável com a folha de março.

Carregando…

Parâmetros do cálculo — taxa, horizonte e sustentação

Estes nove valores entram em todo caso da carteira. Até 01/09/2026 eles só existiam por PUT /api/faro/roi/config — o próprio produto declarava "sem tela ainda" no diagnóstico do ROI. Cada um mostra o intervalo que o motor aceita e o padrão de que ele parte quando ninguém escolhe. Nada é gravado enquanto você digita: a gravação é no botão, porque estes números viram premissa com autor e data.

Carregando…

Subscrições / SKU — o contrato por trás do custo de plataforma

O custo anual da plataforma era um número digitado, sem nós contratados, sem vigência e sem comprovante. Aqui ele passa a ter termo. Nós contratados é o manifest_limit da única regra de conformidade que a Red Hat publica (managed > manifest_limit ⇒ non-compliant). Preço de lista da Red Hat não é público — o valor vem da proposta/PO do cliente. Termo publicado é imutável: renovar cria registro novo apontando o anterior.

Carregando…

Premissas do cálculo — quem responde por cada uma

Premissa sem dono não é erro do sistema: é a informação mais útil desta tela. Ela mostra, antes da reunião, qual número ninguém assumiu — e é sempre por esse que o cliente pergunta.

Carregando…

Discovery por domínio

Perguntas de contexto técnico específicas de cada domínio. Não alteram os 8 fatores universais de complexidade (que são cross-domínio, por design) — só orientam a coleta e alimentam o doc-lookup. Cada pergunta preenche um campo do contexto (vendor / software / versoes / equipamentos / interface).

Domínio

Assessment de adoção

O diagnóstico Red Hat de adoção de automação, em 4 pilares. Cada resposta salva sozinha; cada número mostra a fonte oficial. Não é a quantidade de informação — é a clareza. A qualquer momento você gera o entregável em Excel (abas, respostas predefinidas, fórmulas e ajuda).

Equipe do projeto

Colaboradores e seus papéis. Alimenta o RACI (quem responde o quê): a pessoa certa por domínio.

NomePapelDomíniosE-mailEstadoAções

Squads

Cada projeto tem um squad designado. Os membros vêm da Equipe — e um mesmo colaborador pode participar de vários squads/projetos.

FARO · um produto CodeSolve — a arte de resolver problemas · codesolve.com.br