Consistência sem conexão é custo; conexão sem consistência é caos — por que “ITIL vs. o resto” é uma falsa escolha;

Um mergulho honesto no debate recente sobre ITIL 4, “Humanising IT”, “Value‑Engineering” e a tal “crise de frameworks” — e como sair do ruído com um modelo operativo simples, integrado e verificável.

Antes de começar: um contexto rápido (e 7 perguntas francas):

Você provavelmente chegou aqui porque ouviu que “ITIL ficou caro”, que “não serve para DevOps” ou que “há alternativas modernas”. Antes de comprar um novo rótulo, faça um check honesto da sua realidade:

1. Quando alguém diz “serviço” na sua empresa, isso significa valor percebido ou fila de tickets?
2. Suas mudanças passam por reunião de aprovação ou por evidências no pipeline (testes, segurança, segregação de funções, progressive delivery)?
3. Quais são seus SLOs? Quem os assinou? Como você usa o error budget na tomada de decisão?
4. Seu MTTR caiu nos últimos 90 dias? E a taxa de falha de mudanças?
5. Indicadores de experiência (CSAT/NPS e EX dos times) aparecem no comitê executivo tanto quanto os SLAs?
6. Os princípios da ITIL 4 (keep it simple & practical, start where you are, focus on value) aparecem nas ferramentas do dia a dia — ou só na parede?
7. Você investiu mais em certificação do que em adoção? Por quê?

Passei horas lendo contribuições qualificada­s — concordâncias, críticas e provocações — e destilei aqui o que é sinal (o que muda resultado) e o que é ruído (o que só muda o rótulo). Se alguma pergunta acima incomodou, ótimo: este texto é para você.

1) O fim do mundo (que não aconteceu)

Nos últimos dias, voltei às origens: parei para ler, com calma, dezenas de comentários de profissionais que respeito — gente que vive a operação, que ensina, que desenha políticas, que defende auditorias e que sofre quando elas emperram. Entre elogios, críticas e provocações, a narrativa que mais ecoou foi a de que há um “dilema” em torno do ITIL e de que “novas abordagens” estariam finalmente apontando uma saída.

Aqui vai o meu ponto de partida: não existe dilema onde há dicotomia falsa. “ITIL vs. alternativa” é uma pergunta ruim. O problema nunca foi a ITIL, assim como nunca foi o DevOps, o SRE, o SIAM ou qualquer outro rótulo. O problema é quando confundimos consistência com burocracia e conexão humana com improviso.

Se a sua organização escolhe “consistência sem conexão”, você compra custo. Se escolhe “conexão sem consistência”, você compra caos. Valor nasce entre essas duas coisas — exatamente no ponto em que linguagem comum (ITIL 4) encontra comportamento, design e automação (DevOps/SRE/HCD) e, cada vez mais, IA com guardrails.

2) O que está realmente em disputa

Há três disputas de fundo nessa conversa:

1. Linguagem vs. comportamento. ITIL 4 dá vocabulário, artefatos e um Sistema de Valor de Serviço. Isso é essencial para alinhamento e governança. Só que vocabulário sem comportamentos (acordos de trabalho, feedback honesto, foco em outcomes) não muda a realidade do usuário.
2. Processo vs. ferramenta. Quando o processo vive fora da ferramenta, nasce um ritual paralelo que ninguém respeita. Quando o processo é embutido (regras, automações, templates) a experiência flui — e a governança aparece nas evidências, não nos memorandos.
3. Controle humano vs. automação. Aprovar mudança “na reunião” é custoso e lento. Controlar no pipeline (testes, segurança, segregação de funções, progressive delivery) é mais seguro, mais rápido e mais auditável. Não é menos governança — é outra governança.

“Humanising IT” fala da experiência; “Value‑Engineering” exige evidência. A síntese madura não escolhe um ou outro — ela une experiência + engenharia.

3) Da sala de aula ao gemba: duas implementações que andei vendo

Empresa A fez tudo “direitinho”: onda de certificações, uma dezena de processos mapeados, muitos formulários novos. O backlog de mudança cresceu, a taxa de sucesso melhorou um pouco, mas o MTTR e a percepção do usuário ficaram praticamente iguais. Moral da história: conformidade sem experiência.

Empresa B começou menor: definiu 2 fluxos de valor críticos, tratou serviço como produto (com dono, SLOs e orçamento), implantou mudança por risco dentro do pipeline e treinou post‑mortems sem culpa. No trimestre seguinte, o MTTR caiu, a taxa de falha de mudanças despencou e as pessoas começaram a sentir a diferença. Moral: experiência com consistência.

Não foi um milagre de rótulo. Foi disciplina de adoção.

4) Como conciliar ITIL 4, DevOps/SRE e Design sem inventar moda

Comece pelo serviço como princípio de valor. Se “serviço” é tratado como departamento de baixo prestígio, você perde patrocínio. Se “serviço” é visto como capacidade que permite resultados desejados com gestão de riscos e custos, o jogo muda. Nomeie um owner, defina SLOs que façam sentido para o cliente e crie um roadmap que fale de experiência, não só de SLA.

Mova o controle para o pipeline. Aprovação manual vira fila; evidência automática vira confiança. Policy‑as‑code, feature flags e progressive delivery transformam “change” de cerimônia em engenharia. Auditoria? Fica mais fácil — você prova com logs e gates, em vez de minutes de reuniões.

SRE para além do buzzword. SLOs desenhados com o cliente, error budget para equilibrar estabilidade e evolução, e post‑mortems sem culpa que produzem ações de melhoria reais.

SMO leve. Uma pequena unidade (ou capítulo) que orquestra práticas, dados e melhoria contínua — não para policiar pessoas, mas para habilitar times e evitar regressões. O SMO garante que o processo viva na ferramenta e que métricas conversem entre áreas.

IA com guardrails. Adoção de IA elimina etapas repetitivas e amplia o atendimento, mas exige papéis claros, gestão de risco, MLOps/ModelOps e telemetria de EX/CX para não “otimizar” o que não importa.

5) Quando a crítica procede — e como endereçar

“Ficou burocrático.” Concordo: às vezes fica. A saída passa por políticas enxutas, runbooks curtos, change models automatizados e SLAs de ciclo para o trabalho interno.

“Virou produto, perdeu valor.” Também acontece. Quando o padrão passa a ser vendido como fim em si, o foco escapa do usuário. Remédio: métricas de valor/fluxo/experiência à vista do comitê executivo e treinabilidade acessível no dia a dia.

“Muita alternativa, pouco resultado.” Chame isso de framework fatigue. A resposta é arquitetura: um desenho que deixa claro o que é núcleo (linguagem comum, incident/change/request, melhoria) e o que é opcional por contexto (SRE/DORA para Produto, FinOps/IA para Plataforma, trilhas de auditoria reforçadas para Regulatórios).

6) Julgue por evidências, não por rótulos

Antes de “migrar de doutrina”, pergunte:

• O que melhorou, numericamente, em confiabilidade, velocidade e experiência?
• Como a abordagem se sustenta em ambientes de alto risco e auditoria?
• Existe ecossistema (gente, conteúdo, práticas) para escalar?
• Como isso conversa com o que já funciona (ITIL/ISO/COBIT/DevOps) sem criar retrabalho?
• Se a resposta for fraca, o problema não é a sua “doutrina” — é o processo de adoção.

7) Conclusão

O debate recente trouxe algo precioso: a urgência de reconectar consistência e conexão. O que pagou a conta nas organizações que observei foi uma combinação muito menos glamourosa do que o marketing gostaria: ITIL 4 como língua franca, SRE/DevOps como engenharia do fluxo, design centrado em pessoas como prática diária, automação como controle e dados como árbitro.

Consistência sem conexão é custo. Conexão sem consistência é caos. Valor acontece no encontro das duas.