Como o FARO classifica o que vale automatizar
Faro para o que vale automatizar.
O problema: decidir o que automatizar vira disputa de opinião, e a conta que justificaria a decisão ou não existe ou não se confere. O que este método faz: transforma a decisão numa conta rastreável — cada nota com fator, âncora, fonte e responsável; cada número de dinheiro com premissa, dono e fonte pública que o cliente consegue abrir —, e congela o resultado num registro que o próprio produto reexecuta para conferir se ainda dá o mesmo. Fundamentado em frameworks consagrados do mercado, combinados num trilho único.
Em uma frase
O FARO responde uma pergunta difícil — "de tudo que dá para automatizar, o que fazer primeiro?" — trocando opinião por uma nota justificada para cada caso, e usando essas notas para montar um plano de entrega em etapas. Quem é técnico e quem é de negócio enxergam, juntos, por que cada automação está na fila e quando será feita.
Para quem é de negócio
- Você dá as notas de valor. diz quanto cada automação compensa, com que frequência acontece e quão crítica é.
- Você enxerga a fila. o método mostra, de forma transparente, o que entrega mais oportunidade pelo esforço primeiro.
- Nada é "caixa-preta". toda nota tem origem e responsável — dá para perguntar "por quê?" em qualquer ponto.
- A conta de dinheiro também é feita. o método vai até o retorno — VPL, payback descontado, SIR e AIRR sobre a carteira —, e o caso que não se paga sai com o motivo e o número escritos, não com uma opinião.
Para quem é técnico
- Você dá os fatos técnicos. responde propriedades objetivas (idempotência, check mode, integrações…).
- A régua é a mesma para todo domínio. um "3" em rede custa o mesmo "3" em storage — comparável e reprodutível.
- O cálculo é determinístico. ICO, Quadrante e Bolha saem sozinhos das notas — sem achismo no final.
- O resultado é reprodutível. a régua sai carimbada em cada caso (
regua_versao) e o número da carteira é congelado com os insumos e um hash — que o produto reexecuta depois para dizer se ainda bate.
Não conhece um termo? Há um glossário em linguagem simples ao final. E, em cada quadro com ⓘ, passe o mouse para ver a explicação.
Por que o FARO existe
Toda lista de "o que automatizar" vira disputa de opinião: cada área acha o seu caso o mais importante e o arquiteto arbitra sem base. O FARO existe para acabar com o achismo — transforma a priorização numa conta em que cada nota tem fator, fonte e responsável.
Cada nota vira número numa régua única, igual para todos os domínios: um "3" em rede custa o mesmo "3" em storage (calibração cruzada). A decisão deixa de ser a opinião de um consultor e passa a ser a soma de práticas reconhecidas aplicadas com disciplina.
Uma composição original
Nenhum framework de mercado, isolado, resolve a classificação e priorização de automações ponta a ponta com uma régua cross-domínio. O FARO é a composição original dessas práticas — cada uma usada exatamente na parte onde tem autoridade (ver seção 06). O diferencial não é uma fórmula secreta: é a orquestração disciplinada de padrões reconhecidos numa régua reprodutível.
Três momentos, nove passos
Mnemônico I·A·O. Cada passo tem objetivo, fundamento, RACI (quem responde), gate (critério para avançar) e onde vive na plataforma.
Inventariar
Descobrir e catalogar os casos de uso candidatos.
Avaliar
Classificar de forma defensável, por números de fonte confiável.
Orquestrar
Priorizar, validar com o cliente e entregar o que vale.
Guia rápido do método
Duas leituras: como ler uma classificação pronta e como usar o método para produzir uma.
Como ler uma classificação
- Siga a cadeia. de cada nota, abra fator → âncora → fonte → quem respondeu. Se a cadeia fecha, a nota é defensável.
- Leia os três índices — e depois o dinheiro. ICO = risco de operar; Quadrante = estratégia; Bolha = oportunidade. Os três ordenam candidatos; quem responde "compensa?" é o VPL, na tela de Retorno do investimento.
- Olhe o gráfico. mais à esquerda e mais alto = melhor (alto valor, baixa complexidade). Bolha grande = mais retorno pelo esforço — o tamanho serve para ordenar, não para medir: o raio tem um piso, então o dobro de área não vale o dobro. Para comparar, use o número.
Como usar (produzir uma)
- Cadastre o caso de uso no estado puro — ID, domínio, descrição, contexto técnico.
- Responda os fatores por competência fatos técnicos: especialista de domínio + arquiteto; notas de negócio: cliente.
- Deixe os índices calcularem ICO/Quadrante/Bolha saem sozinhos das notas.
- Valide e priorize o cliente confirma o negócio; o caso entra numa onda.
- Rode o retorno o motor calcula VPL, payback descontado, SIR/AIRR, o cenário de estresse e a simulação — e diz o que ficou de fora e por quê.
Como o Volume/Frequência é calculado
O Volume/Frequência não é perguntado ao cliente — é derivado do as-is (a descrição de como o processo é feito hoje). Assim o mesmo fato é capturado uma única vez e a nota sai sem achismo.
A fórmula, em quatro passos
- Do as-is dois campos: nº de hosts/alvos por execução e a frequência (quantidade × período).
- Anualizar a frequência multiplica pelo período: carregando….
- Volume bruto (X) X = hosts × frequência/ano — o total de execuções-alvo por ano.
- Faixa → nota 1–5 X é enquadrado na tabela ao lado; a nota entra na Bolha = (Valor × Volume × Criticidade) ÷ Complexidade.
Faixas (X → nota)
| Execuções-alvo/ano (X) | Nota | Leitura (desta página) |
|---|---|---|
| carregando as faixas da régua… | ||
Na tela Classificar, o card do Volume traz um "🧮 como é calculado" com estes números já aplicados ao caso de uso aberto — se um valor não fecha, ajuste os campos de hosts e frequência no as-is (botão “i” do caso de uso).
Como aplicar — do primeiro caso ao roadmap
Um roteiro que qualquer pessoa da equipe consegue seguir. Cada passo diz o que fazer, quem faz (pela competência) e onde vive na plataforma.
| # | O que fazer | Quem faz | Onde na plataforma |
|---|---|---|---|
| 1 | Descrever o caso — o que se quer automatizar em 1 frase + contexto técnico (equipamentos, software, versões) | quem conhece a demanda | Casos de uso → Criar |
| 2 | Descobrir a documentação/collection oficial da tarefa | especialista | Doc-lookup |
| 3 | Responder os fatos técnicos (fatores objetivos) → o sistema calcula Complexidade e Risco | especialista + arquiteto | Classificar |
| 4 | Responder as notas de negócio — Valor e Criticidade (o Volume é derivado de hosts×frequência do as-is) | cliente / dono do negócio | Classificar |
| 5 | Conferir os índices que se calculam sozinhos — ICO, Quadrante, Bolha | automático | Classificar / Priorização |
| 6 | Ratificar as premissas econômicas — custo-hora, tabela de custo, tempo manual, taxa de desconto, horizonte, custo da plataforma… cada uma com dono nomeado, procedência e data de revisão | controladoria + lead do escritório | Base econômica → Premissas do cálculo |
| 7 | Rodar o retorno — VPL, payback descontado, SIR/AIRR, cenário de estresse e simulação; o que não se paga aparece em “o que ficou de fora e por quê” | automático | Retorno do investimento |
| 8 | Vincular o caso a um projeto (sai do backlog) | lead / arquiteto | Casos de uso → Vincular |
| 9 | Organizar em ondas — o método recomenda abrir com uma onda read-only (ADR-FARO-004 §5), mas o nível de cada onda vem do plano do projeto; quem decide quem entra é o gate de risco (Risco acima do teto daquela onda, o caso não entra), não o quadrante: um Quick Win de Risco alto fica para uma onda de nível maior | lead / arquiteto | Projetos → Ondas |
| 10 | Entregar onda a onda, com aprovação (gate) entre elas | equipe + cliente | Projeto / Priorização |
| 11 | Congelar o número antes de levá-lo à decisão — o snapshot guarda insumos, as duas réguas e um hash; a rota de reprodução reexecuta e diz se o número volta igual | lead / arquiteto | Retorno do investimento → Snapshots |
Números de fontes confiáveis, de forma transparente
Como classificar um caso de uso por números, obtidos de fontes confiáveis, de forma clara e auditável — sem nada "digitado à mão" no final. A resposta é uma cadeia rastreável por fator (passe o mouse no ⓘ de cada quadro):
--check confiável a regra confirma o teto, não o eleva.Os índices se calculam sozinhos a partir das notas (Passo 5 — gate: nada à mão):
Risco de operar
o quão perigoso é rodar o caso.
Estratégia
quick win · estratégico · eficiência · reavaliar.
Oportunidade
o retorno relativo do caso.
Depois da nota, o dinheiro — e ele pode dizer não
Classificar responde "o que é mais fácil e mais valioso". Não responde "compensa?". Essa segunda pergunta tem motor próprio no FARO, e é a lente que rejeita caso: a carteira fica com o que se paga, e o que não se paga sai dela com o motivo e o número escritos.
| O que o motor publica | O que a medida responde |
|---|---|
| VPL | o saldo do programa trazido a dinheiro de hoje. Positivo = dentro do horizonte analisado, o conjunto se paga. |
| Payback descontado | em quantos anos o caixa acumulado já descontado vira positivo. O FARO publica o descontado, não o simples — o NIST HB 135 §6.4 trata os dois e diz por que o simples não decide: ele "ignores the time-value of money". |
| SIR e AIRR | quanto de economia por unidade investida, e a taxa de retorno equivalente (NIST HB 135, Eq. 6-3 e Eq. 6-6). O manual recomenda o AIRR no lugar da TIR, porque sai de fórmula direta enquanto a TIR precisa ser aproximada por iteração. |
| TIR | publicada porque é a medida que o comitê pede — e sempre acompanhada do AIRR, que é a régua que a fonte prefere. |
| Economia de caixa × custo evitado | em colunas separadas, como a OMB Circular A-131 exige. Somar as duas numa linha só é o jeito mais comum de um business case parecer melhor do que é. |
| Cenário de estresse | o VPL recalculado com os uplifts de viés otimista do HM Treasury aplicados ao custo. |
| Simulação | Monte Carlo sobre benefício e custo, publicando P10 / P50 / P90 e a probabilidade de o VPL ficar positivo. Desde o ADR-FARO-035, o estouro de construção e o de recorrente são sorteados separados — são riscos diferentes, e a fonte manda separá-los. |
| Switching value | de quanto uma premissa teria de mudar para virar a decisão (Green Book 2026 §6.105). É o que transforma "não se paga" numa pergunta respondível: este caso precisaria valer tanto por ano em benefício não monetizado — vale? |
O horizonte não é constante do método — é do investidor
Quantos anos a análise cobre é premissa do cliente, não parâmetro escondido do FARO. NIST HB 135 §2.4, verbatim: "there is no one correct study period". A norma impõe outra regra, e o motor a respeita: o mesmo período entre as alternativas comparadas — e esta análise compara automatizar contra não automatizar. O valor em vigor é premissa com dono registrado e aparece na tela ao lado do número que ele produz. Encurtar o horizonte até o programa parecer não se pagar, ou esticá-lo até parecer que se paga, são o mesmo erro; por isso mudá-lo é decisão registrada, com o payback medido como evidência.
O que acontece com o caso que não fecha
Ele não some. Vai para “o que ficou de fora e por quê”, que separa decisão registrada (alguém olhou e decidiu) de cadastro incompleto (falta dado para decidir). O motivo vem de vocabulário fechado — VPL negativo sem valor não monetizado assumido, risco inaceitável, fora do escopo contratual, resolvido por outro meio, serviço descontinuado pelo cliente — com decisor nomeado e data. E o inverso vale igual: manter na carteira um caso que não se paga exige uma das três afirmações verificáveis (alguém nomeado assumiu o valor não monetizado; existe obrigação normativa ou contratual; o caso é habilitador de outro, nomeado). Quem assume é uma pessoa — nunca o modelo.
Premissa tem dono, fonte tem endereço, número tem como ser reexecutado
É a parte do método que não aparece em gráfico nenhum — e é a que sustenta a reunião difícil. Quatro garantias, cada uma com uma porta no produto.
1 · Toda premissa econômica tem ficha própria e dono nomeado
O vocabulário de premissas é fechado: o valor da hora e a tabela de custo vigente, o tempo que a tarefa leva hoje à mão, a taxa de desconto, o horizonte, o custo anual da plataforma, quanto da hora liberada vira valor de verdade, e os três parâmetros que dimensionam a sustentação. Cada uma carrega quem responde por ela, de onde o número veio (medido · derivado · estimado · referência) e até quando revisar. E herdar o dono do business case não é assinar: quando ninguém assinou aquela linha, a API responde (dono não registrado) em vez de exibir um nome emprestado (ADR-FARO-033). Premissa sem dono não trava o cálculo — vira pergunta em aberto no relatório, que é onde ela deve estar antes de virar surpresa na reunião. Onde vive: Base econômica → Premissas do cálculo.
2 · Fonte paga não é citada
Citação que o cliente não consegue abrir não é procedência — é apelo à autoridade. O ADR-FARO-031 fechou a tabela e tirou do motor as últimas fontes pagas: ISO 15686-5, ISO/IEC/IEEE 14764, IEC 31010, ASTM E1121 e CIPS. Nenhuma foi apenas apagada: cada uma foi substituída por fonte gratuita e pública já ingerida no acervo que o próprio produto consulta — NIST Handbook 135 (2020), HM Treasury Green Book 2026 e OMB Circular A-131. E o expurgo não é promessa: as cinco ficam num registro de fontes desreconhecidas que é varrido a cada rodada, dentro do motor e na projeção que sai para o cliente.
3 · O número da carteira vira snapshot, e o snapshot se reexecuta
Antes de ir para uma decisão, o número é congelado: o snapshot guarda os insumos, a régua de classificação e a régua econômica daquele instante, e um hash da entrada. Depois, a rota de reprodução reexecuta os insumos congelados e responde se o hash confere, se as duas réguas ainda são as da emissão e se a saída reproduzida bate com a carimbada — com veredito e explicação em texto. Régua que muda não corrompe o histórico: o snapshot antigo passa a responder “a régua mudou”, que é a resposta certa, em vez de recalcular calado (ADR-FARO-027). Dois relatórios com a mesma régua ainda podem divergir por decisão de escopo — por isso o snapshot também guarda quem estava rejeitado.
4 · As garantias são reexecutáveis, e não só afirmadas
Garantia que não se reexecuta vira folclore. As afirmações desta entrega ficam num conferidor único, que roda todas de uma vez: a régua de classificação continua a mesma; os números da carteira não se moveram; nenhuma fonte paga voltou ao motor nem à saída pública; nenhuma premissa ficou sem ficha e nenhum dono foi afirmado sem nome; todo ADR citado no código existe de fato; os documentos que o cliente lê declaram a régua sob a qual foram escritos; a suíte está verde; e a demonstração ainda se reproduz a partir do próprio dataset. Ele termina em erro se qualquer uma falhar — que é a diferença entre uma garantia e um adjetivo.
O que o slogan promete
"Faro" não é só sigla. Um faro rastreia, segue a pista e separa o que vale do que não vale — exatamente os três momentos:
| Inventariar = farejar / rastrear | descobrir candidatos e catalogar a pista (Passos 1–2) |
| Avaliar = seguir a pista com critério | medir cada caso por números de fonte confiável, não por instinto (Passos 3–5) |
| Orquestrar = decidir o que vale | priorizar, validar com o dono do negócio e entregar o que compensa (Passos 6–9) |
E o slogan de quem faz
O FARO é um produto CodeSolve, cujo slogan é “a arte de resolver problemas”. O problema aqui é nomeável: a decisão de o que automatizar não tinha conta, e a conta que existia não se conferia. A parte de resolver são os nove passos acima. A parte de arte é o que este método cobra de si mesmo e quase nenhuma ferramenta de priorização cobra — que cada número tenha origem, dono e fonte que o cliente consiga abrir, e que o resultado possa ser reexecutado depois para conferir se ainda dá o mesmo. Resposta que ninguém consegue verificar não resolveu o problema: só o adiou.
Complexidade é propriedade técnica do Ansible — não do domínio
O esforço e o risco de automatizar não derivam de o que a tarefa faz (rede, storage, virtualização), mas de como o Ansible a executa. Essas propriedades são as mesmas em qualquer domínio — por isso a mesma régua vale para todos.
Idempotência
Um módulo idempotente "sai sem executar ações" quando o estado desejado já existe. Com módulo idempotente = baixa complexidade em qualquer domínio; sem garantia = alta. docs.ansible.com · playbooks_intro
Check mode (--check / dry-run)
Roda sem alterar e reporta o que mudaria — mas módulos sem suporte "não reportam e não fazem nada", tornando o dry-run enganoso. Testabilidade é propriedade técnica. docs.ansible.com · check mode
Resource modules
Padronizam a gerência por estado (merged/replaced/overridden/…) e retornam before/after/commands, permitindo asseverar not changed. O padrão de complexidade acompanha o módulo, não o domínio. docs.ansible.com · resource modules
Comando cru (command/shell) = sinal de maior complexidade/risco
Só tem check mode parcial e a doc recomenda o módulo específico. Recorrer a comando cru é abrir mão de idempotência nativa e dry-run confiável — em qualquer domínio. docs.ansible.com · command
Os 8 fatores objetivos (Passo 4)
Cada fator mede complexidade/risco por uma propriedade técnica verificável — não por opinião. 8 fatores (q1..q8). A régua vigente no motor é faro-1.3 e sai carimbada em regua_versao no formato faro-1.3+q<sha8>+c<sha8> — sempre, de fábrica ou editada (q = impressão digital dos fatores, c = das constantes do motor).
| # | Fator | Por que mede (âncora técnica) |
|---|---|---|
| 1 | Nº de sistemas/plataformas | cada alvo a mais multiplica pontos de falha e estado a convergir |
| 2 | Módulo pronto (certified) vs. comando cru | módulo sai sem ação se já no estado; comando cru não garante isso |
| 3 | Ordem / estado | dependência de ordem/estado é risco documentado (ex.: overridden pode remover seu acesso) |
| 4 | Reversibilidade da operação | operação irreversível eleva o Risco por si só (a própria escala de q4 vai a 5) |
| 5 | Nº de exceções por modelo/versão | cada exceção quebra a experiência consistente do resource module |
| 6 | Interface API / CLI / UI | API tende a módulo idempotente; CLI empurra para comando cru; UI é frágil |
| 7 | Dry-run (--check) confiável | check mode enganoso (módulo sem suporte não reporta): sobre operação que altera estado, --check parcial soma +1 ao Risco e a ausência de --check confiável soma +2 — até o teto da escala, 5. Em somente leitura não soma nada: não há mudança a reverter |
| 8 | Lógica / decisão condicional | check mode não prevê conditionals sobre variáveis registradas |
Como a nota é calculada, passo a passo
Esta é a mecânica completa. O que não é publicado está dito no fim — e o motivo também.
| Etapa | O que acontece |
|---|---|
| 1. Quais fatores contam | Dos 8 fatores, 6 formam a Complexidade (1, 2, 3, 5, 6 e 8). O fator 4 (reversibilidade) forma o Risco; o fator 7 (dry-run) é modificador do Risco. Complexidade e Risco são notas independentes. |
| 2. Soma | Cada resposta dos 6 fatores vale um ponto conforme quão adversa ela é dentro da própria pergunta. Os pontos são somados — sem pesos por fator: nenhum dos 6 vale mais que outro. |
| 3. Faixa | A soma cai numa faixa de 1 a 5. Faixa, e não regra de três: a diferença entre "toca 2 sistemas" e "toca 3" não é linear, e fingir que é produziria precisão falsa. |
| 4. Regra de piso | O gatilho é módulo certified + um único sistema + operação somente leitura. Mas quem decide é a soma dos seis fatores de construção, não cada fator isolado: a Complexidade só vai a 1 se o acumulado couber dentro do teto da regra. Duas consequências que a tela mostra caso a caso: um fator sozinho na pior opção pode conviver com o piso, desde que a soma caiba; e o gatilho não basta — com o acumulado acima do teto a regra não se aplica, a nota continua a da faixa, e a tela diz isso com o motivo. Ser somente leitura reduz o Risco, não a Complexidade. |
| 5. Regra de interface | Se a tarefa só existe por tela (UI/scraping), a Complexidade vai a 4: automação por tela quebra a cada mudança de layout, e o método trata isso como complexidade alta por definição. Esta regra roda depois da regra de piso e prevalece sobre ela — quando as duas disparam no mesmo caso, a nota final é 4, não 1. O piso mede o acumulado dos fatores de construção; a interface por tela é um mínimo que o método impõe, e por isso é a última palavra. |
| 6. Modificador do Risco | O Risco sai do fator 4 (reversibilidade). O fator 7 (dry-run) o modifica, e só sobre operação que altera estado: --check parcial soma +1, ausência de --check confiável soma +2, e a soma para no teto da escala, 5. Em somente leitura a resposta fica registrada e não muda o Risco — não há mudança a reverter. Efeito colateral honesto: nesta régua o Risco 2 não é alcançável; os valores possíveis são 1, 3, 4 e 5. |
| 7. ICO | ICO = MAX(Complexidade, Risco) — o maior dos dois, nunca a média. Um caso simples que derruba produção é caso de alto risco, e a média o esconderia. |
O que a tela mostra em cada caso classificado
Abra qualquer caso → Origem desta nota. Aparecem: as 6 respostas que entraram, cada uma marcada como melhor · meio · pior dentro da própria pergunta; quantas estão na pior opção; as regras de salto aplicadas e as não aplicadas, com o motivo; e o contrafactual — “se esta resposta fosse X, a nota seria Y”.
O que não é publicado, e por quê
Quanto cada resposta vale e onde ficam os cortes entre as faixas são propriedade do método (ADR-FARO-009) e ficam no servidor — nem a tela de administração da régua os exibe. É essa régua que faz a avaliação ser consistente entre clientes e ao longo do tempo: dois casos iguais em empresas diferentes recebem a mesma nota. O que se publica é tudo que entrou na conta e o que mudaria o resultado — que é o que permite conferir a nota sem precisar da régua.
Reversibilidade (4) e --check (7) são fatores separados. A idempotência comprovável (not changed na 2ª execução) é a âncora de verificação do método — não um fator pontuado. Credenciais / pré-requisitos são campo do as-is, não fator. Fontes: documentação oficial Ansible; motor faro-1.3, a régua vigente (a versão efetivamente usada sai carimbada em regua_versao em cada caso classificado).
Qual parte de cada framework usamos — e como
Cada peça entra no passo onde tem autoridade. Não usamos o framework inteiro — usamos a parte específica que resolve aquele ponto. verificado = confirmado por acesso; n/c = domínio oficial, mas bloqueado a robô (403).
| Framework | Qual parte usamos | Como usamos no FARO | Fonte |
|---|---|---|---|
| PMI / PMBOK | a Matriz de Responsabilidades (RAM/RACI) | define, por nota, o único responsável — Passo 3 | pmi.org 403 |
| TOGAF ADM | a descoberta estruturada por domínios de arquitetura | organiza o levantamento de casos por domínio — Passo 2 | opengroup.org ok |
| ITIL 4 | a prática de Change Enablement | rege mudança em produção e governança — Passos 1 e 9 | axelos.com n/c |
| Scrum / SAFe | a cadência em intervalos (Planning Interval) | entrega em ondas priorizadas — Passo 6 (não a cerimônia completa) | scaledagile.com ok |
| Wideband Delphi | a calibração de estimativa por consenso | alinha as notas 1–5 entre especialistas, reduzindo viés — Passo 4 | ref. ok |
| IFPUG / COSMIC | o conceito de medir tamanho indep. de tecnologia (proxy) | inspira a régua de complexidade cross-domínio — Passo 4 (não contagem certificada) | cosmic-sizing.org ok |
| DORA | as 4 métricas de entrega | medem o desempenho da entrega das automações — Passo 9 | dora.dev ok |
| ADR | o registro de decisão (contexto + trade-offs) | toda decisão relevante vira um ADR — Passo 9 | adr.github.io ok |
| Modelo C4 | os níveis de diagrama (contexto/contêiner) | desenham a arquitetura das soluções — Passo 9 | c4model.com ok |
E do lado econômico
A conta de retorno tem a mesma exigência da classificação: cada constante e cada regra apontam para um documento que o cliente consegue abrir. É por isso que as fontes pagas saíram do motor (ADR-FARO-031) — e foram substituídas, não apenas removidas.
| Fonte | Qual parte usamos | Como usamos no FARO |
|---|---|---|
| NIST Handbook 135 (2020) normativa · gratuita | o custo de ciclo de vida (Eq. 5-2), SIR e AIRR (Eq. 6-3 e 6-6), payback simples × descontado (§6.4), o study period (§2.4), Monte Carlo (§8.6.3), manutenção preventiva como categoria própria (§17.4) | é a espinha do cálculo: define as medidas publicadas, a regra do horizonte e o tratamento da incerteza |
| HM Treasury — Green Book 2026 normativa · gratuita | a linha de base business as usual (§4.15), o switching value (§6.105), a proibição de reprovar por limiar de BCR (§6.98–6.99), sensibilidade obrigatória para a opção preferida (§6.104), estimativa em preços reais (§6.46–6.47) | define contra o quê se compara e o que precisa ser publicado ao lado do número |
| HM Treasury — Optimism Bias guia suplementar · gratuito | os uplifts por categoria de projeto e a instrução de separar o viés de construção do de operação | o cenário de estresse, e os dois fatores de estouro sorteados em separado (ADR-FARO-035) |
| OMB Circular A-94 / A-131 normativa · gratuita | a proibição de misturar regime real e nominal; custo afundado fora da análise; a definição de cost savings × cost avoidance em colunas separadas | o regime monetário do motor e a separação entre economia de caixa e custo evitado |
| COCOMO II orientativa | o fator de mudança da manutenção (Eq. 8) e o multiplicador de adaptação (Eq. 10) | dimensiona o custo de sustentar a automação depois de pronta — inspirado em, não COCOMO II aplicado |
| Red Hat — ROI de automação orientativa | a fórmula ex ante: recaptura de produtividade e ajuste de risco sobre o benefício | a base do benefício bruto, antes do contrafactual e da curva de adoção |
| Forrester TEI orientativa | ROI sobre valor presente, ano 0 não descontado, assimetria do ajuste de risco (custo sobe, benefício desce), faixa usual de desconto | convenção de apresentação do número — não o critério de decisão |
Cada linha da conta carrega, na própria saída do cálculo, a citação com parágrafo e — quando o trecho foi conferido — o texto verbatim. O que é convenção da casa e não norma sai rotulado como tal, no mesmo lugar. Ver as Ressalvas honestas ao final.
O que a Red Hat sustenta — e o que não
O FARO ancora peças oficiais Red Hat — cada uma rotulada: (a) produto (normativo) ou (b) serviços/marketing (orientativo). O que fica em roadmap é a integração com o Automation Savings Planner da Red Hat — não a quantificação de valor: o FARO tem motor de ROI próprio (VPL, payback descontado, TIR, SIR e AIRR, com cenário de estresse, simulação e switching value), e é ele que rejeita caso que não se paga.
| Peça | Rótulo | Passo | Qual parte / papel |
|---|---|---|---|
| Maturidade — 5 estágios | (b) | 1 | posiciona a evolução (autoavaliação, não certificação) |
| Services Journey — fase Discuss | (b) | 2 | descoberta de casos + envolver especialistas (SMEs) |
| Automation Savings Planner roadmap | (a) | — | a integração com esta peça Red Hat é que fica em roadmap. Os campos hosts×frequência do as-is alimentam o Volume derivado (ADR-FARO-010) e também a economia de horas do motor de ROI do FARO (roi_carteira: hosts × frequência × tempo manual) — a projeção financeira existe e é ofertada, na tela Retorno do investimento. |
| Automation Hub — certified/validated | (a) | 8 | ordem de preferência certified→validated→community |
Fontes: Maturity e-book · Services Journey brief · Savings Planner AAP 2.5 / AAP 2.4 · Managing content.
Termos em linguagem simples
Para quem não é da área técnica — cada termo do método em uma frase do dia a dia.
| Caso de uso (UC) | uma automação candidata — algo que se quer automatizar (ex.: "fazer backup da configuração dos switches"). |
| Backlog | a lista de casos ainda sem projeto — a "fila de espera". |
| Complexidade (1–5) | o quanto é difícil/trabalhoso automatizar. 1 = trivial, 5 = muito complexo. |
| Risco (1–5) | o quanto pode dar errado ao executar. Só ler = baixo; apagar algo sem volta = alto. A escala é 1–5, mas nesta régua a nota 2 não é alcançável: os valores que saem são 1, 3, 4 e 5. Não é falha — é a consequência de o Risco partir da reversibilidade e ser modificado pelo dry-run. |
| Valor / Volume / Criticidade | o lado do negócio: quanto compensa e quão crítico é (Valor e Criticidade são do cliente). O Volume — com que frequência acontece — é derivado de hosts×frequência do as-is, não perguntado. |
| ICO | "quão perigoso é operar" — o maior entre Complexidade e Risco (Baixo/Médio/Alto). |
| Quadrante | a estratégia: alto valor + baixa complexidade = "quick win" — candidato a entrar cedo, não "fazer já": quem decide a onda é o gate de risco, e o quadrante não olha para reversibilidade. |
| Bolha (Oportunidade) | o retorno pelo esforço — quanto maior a bolha, mais vale a pena. O tamanho ordena, não mede: como o raio tem um piso para o caso pequeno não sumir da tela, dobrar a Oportunidade aumenta a área bem menos que o dobro. Para comparar dois casos, use o número da Oportunidade, não o desenho. |
| RACI | quem responde o quê: o técnico responde os fatos técnicos; o cliente, as notas de negócio. |
| Onda | uma etapa de entrega do projeto, com data, objetivo e um nível de risco declarado (read-only, reversível ou alto risco) que é o teto do gate. O método recomenda abrir pelos casos mais seguros; o nível real de cada onda vem do plano do projeto. |
| Idempotência | rodar a automação duas vezes dá o mesmo resultado, sem estragar nada — o "padrão-ouro". |
Check mode (--check) | o "ensaio" da automação: mostra o que mudaria, sem mudar de verdade. |
| Collection (certified / community) | peça pronta do Ansible. "Certified" = com suporte oficial; "community" = sem suporte (exige autorização). |
| Comando cru | quando não há peça pronta e é preciso "mandar o comando na mão" — mais arriscado. |
| Período da frequência | o vocabulário aceito para "de quanto em quanto tempo": dia, semana, quinzena, mês, bimestre, trimestre, semestre e ano. É fechado de propósito — cada termo tem um multiplicador fixo, e um termo fora da lista devolve "período desconhecido" em vez de virar zero em silêncio. |
| CAPEX | o investimento: o que se gasta uma vez para a automação passar a existir — as horas de construção do caso e a plataforma que vai executá-lo. |
| OMR | operation, maintenance and repair — o custo de manter viva a automação depois de pronta, ano a ano. É a linha que a maioria das contas de ROI esquece; aqui ela existe e tem método. |
| LCC | life-cycle cost, o custo de ciclo de vida: investimento + reposições − valor residual + operação e manutenção. O que a decisão custa de ponta a ponta, não só a fatura de entrada (NIST HB 135, Eq. 5-2). |
| VPL | valor presente líquido: tudo o que entra menos tudo o que sai, trazido para dinheiro de hoje pela taxa de desconto. Positivo = no horizonte analisado, o conjunto se paga. |
| Payback descontado | em quantos anos o caixa acumulado vira positivo já descontado. Diferente do payback "simples", que finge que dinheiro daqui a cinco anos vale o mesmo que dinheiro hoje — por isso o FARO publica o descontado. |
| TIR | taxa interna de retorno: a taxa de desconto que zeraria o VPL. Publicada porque é o que o comitê pede — e sempre ao lado do AIRR, que é a medida que a fonte recomenda no lugar dela. |
| SIR | savings-to-investment ratio: valor presente das economias ÷ valor presente do investimento. Acima de 1 = as economias superam o que se investiu. Serve para ordenar projetos independentes sob orçamento; a fonte proíbe usá-lo para escolher entre alternativas que se excluem — nesse caso o critério é o menor custo de ciclo de vida. |
| AIRR | adjusted internal rate of return: a taxa de retorno equivalente ao SIR ao longo do período. O manual do NIST a recomenda sobre a TIR porque sai de fórmula direta, enquanto a TIR precisa ser aproximada por iteração. |
| BCR | benefit-cost ratio: valor presente dos benefícios ÷ valor presente dos custos. O Green Book é explícito em que não se reprova uma proposta só por ela ficar abaixo de um limiar, e em que um BCR menor que 1 ainda pode representar bom uso do dinheiro. Por isso o FARO publica o número e o argumento, não um carimbo. |
| MCF | maintenance change factor: quanto do que já foi automatizado muda por ano. É ele que dimensiona a sustentação — automação em cima de um alvo estável custa pouco para manter; em cima de um alvo que muda toda hora, não. |
| Switching value | de quanto uma premissa teria de mudar para virar a decisão. É o que transforma "não se paga" numa pergunta respondível — precisaria valer tanto por ano em benefício não monetizado; vale? — em vez de num veto. |
| Premissa com dono | cada número que entra na conta econômica tem uma pessoa que responde por ele, uma procedência (medido · derivado · estimado · referência) e uma data de revisão. Sem isso a conta é de ninguém — e é sempre por aí que o cliente pergunta. |
| Snapshot | a foto congelada do cálculo: insumos, as duas réguas e um hash. Serve para o número de uma reunião poder ser reexecutado meses depois e conferido — e para a régua evoluir sem reescrever a história. |
Ressalvas honestas
É a honestidade que torna o método defensável. Por isso estas ressalvas ficam à vista, não em rodapé:
O que é FARO, o que é framework de terceiro
- A régua de complexidade 1–5 é artefato do método FARO. A Red Hat não publica uma régua formal de "complexidade 1–5". Não confundir com a régua de maturidade de 5 estágios (essa sim é Red Hat) — coisas diferentes com o mesmo número "5".
- IFPUG / COSMIC são usados como proxy conceitual (inspiração para medir tamanho independente de tecnologia) — não é contagem certificada de Function Points.
- O ROI do FARO é entregável ativo — VPL, payback descontado, TIR, SIR e AIRR, com cenário de estresse, simulação e switching value; é a lente que rejeita caso. O que segue em roadmap é a integração com o Automation Savings Planner da Red Hat, que é outra peça e outro cálculo: lá é simplesmente custo manual − custo automatizado, e "risk-adjusted" não existe na documentação dele. Não apresente um como se fosse o outro.
- As ondas são inspiradas em Scrum/SAFe, mas são adaptação local — não uma cerimônia SAFe formal. Terminologia atual: PMBOK usa RAM; SAFe usa Planning Interval.
- Nem tudo no motor econômico é norma — e o que é convenção da casa diz que é. A curva de adoção do primeiro ano, a moda e o teto do fator de estouro de custo, o fator sistêmico da simulação, a correlação entre os fatores de custo e o piso de 3% de manutenção preventiva são convenções declaradas do FARO, não normativas. O piso de 3% merece nota própria: a categoria "manutenção preventiva" é do NIST HB 135 §17.4, mas a fração é nossa — nenhuma fonte livre publica esse número, e uma norma paga chegou a ser citada por ele antes de o ADR-FARO-031 a retirar, justamente por ser "convenção da casa vestida de norma". Elas saem rotuladas assim na própria saída do cálculo, ao lado das que têm citação com parágrafo e página. Trocá-las pelo dado real do cliente é melhoria esperada — não conserto de defeito.
- O horizonte é do investidor, não do FARO. Não existe período de análise correto único; o que o método cobra é que ele seja o mesmo entre as alternativas comparadas, que tenha dono registrado e que apareça ao lado do número que produziu. Escolher o horizonte depois de ver o resultado é escolher o número que agrada — e é por isso que mudá-lo vira decisão registrada, com evidência medida.
- A simulação não promete probabilidade de sucesso do projeto. Ela publica P10, P50, P90 e a probabilidade de o VPL ficar positivo sob as distribuições declaradas — e essas distribuições são, em parte, convenção da casa. Quando o VPL simulado cruza o zero, o coeficiente de variação perde significado e não é publicado: a saída diz isso e manda ler o desvio padrão e a faixa P10–P90.
- A régua de complexidade não é publicada, e essa escolha tem custo. Quanto cada resposta vale e onde ficam os cortes entre as faixas ficam no servidor (ADR-FARO-009). Em troca publica-se tudo que entrou na conta e o que mudaria o resultado. Quem quiser refazer a aritmética por fora não consegue; quem quiser conferir se a nota está certa, consegue.