O que é ITSM e ITIL, e qual a diferença entre os dois

ITSM é a disciplina de entregar tecnologia como serviço, com processo, papel e métrica definidos, partindo da necessidade de quem usa. ITIL é o framework que descreve como implementar isso na prática, hoje na versão 4.

A relação entre os dois é a fonte de quase toda a confusão sobre o assunto, e ela tem um atalho: ITSM é para ITIL o que ágil é para Scrum. Uma define o objetivo, a outra descreve o caminho.

E há uma razão para isso importar mesmo para quem trabalha só com produto digital. Depois que o software entra em produção, o trabalho muda de natureza. Deixa de ser projeto, que tem fim, e passa a ser serviço, que tem nível acordado. Quem trata a operação como continuação do projeto descobre isso do jeito difícil.

O que o ITSM propõe

A leitura mais comum, e errada, é que ITSM significa organizar a área de TI. Não é isso. A ideia é partir da necessidade de quem usa e desenhar o serviço para atendê-la, em vez de partir do que a TI já sabe fazer.

Três consequências práticas disso.

A entrega passa a ser tratada como serviço, o que vai bem além do suporte convencional. Abrange o ciclo de vida completo: como o serviço é desenhado, entregue, sustentado, medido e melhorado.

O controle é ponta a ponta. Uma solicitação que atravessa três áreas continua sendo um serviço só, com alguém respondendo pelo resultado, e não três filas independentes.

E as métricas de TI passam a se alinhar aos objetivos do negócio. Disponibilidade e tempo de resolução deixam de ser indicador interno da área e passam a ser compromisso com quem depende do serviço.

ITSM, ITIL e DevOps

Vale separar os três, porque as pessoas costumam colocá-los no mesmo nível e depois discutir qual escolher, quando eles não são alternativas entre si.

ITSM é a abordagem estratégica. Define claramente papel e responsabilidade na entrega do serviço, para cada pessoa, time e departamento.

ITIL é o corpo de práticas que descreve como executar. É o "passo a passo", ou pelo menos era, antes da versão 4.

DevOps é a filosofia de aproximar quem desenvolve de quem opera, removendo impedimento entre as duas e acelerando o caminho até produção.

Ou seja: ITSM e ITIL falam de como o serviço é gerido; DevOps fala de como a mudança chega em produção. Não competem, atuam em pontos diferentes do mesmo fluxo.

Os processos que sustentam a operação

Seis processos cobrem a maior parte do que uma operação precisa.

Gestão de incidente. Um serviço falhou ou degradou, e o objetivo é restaurar o mais rápido possível. A parte que decide a qualidade aqui é a capacidade de priorizar e categorizar por impacto no negócio, e não por ordem de chegada. É o que direciona esforço para onde ele rende mais.

Gestão de problema. Parecida com incidente, e não igual. Incidente é a interrupção acontecendo; problema é a causa por trás de incidentes que se repetem. A gestão de problema existe para eliminar essa causa e estabilizar o serviço.

Pode ser lida como um segundo nível do atendimento, ou como a função responsável por eliminar erro recorrente de alto impacto. Na prática é a diferença entre um time que apaga incêndio e um time que reduz a quantidade de incêndios. Time que só trata incidente apaga o mesmo para sempre.

Gestão de mudança. Garante que atualização em sistema ou infraestrutura seja planejada, agendada e documentada, com as pessoas certas disponíveis caso algo saia errado.

Aqui existe uma tensão real com DevOps, e é melhor nomeá-la do que fingir que não existe. Mudança bem gerida não significa mudança rara: significa mudança rastreável e reversível. O ITIL 4 reconhece isso, e a prática chama-se habilitação de mudança, não controle de mudança. A diferença de nome carrega a diferença de intenção.

Gestão de nível de serviço. Acompanha os compromissos acordados, identifica ponto fraco e dispara ação corretiva. É o processo que dá sentido ao acordo de nível de serviço.

Gestão de solicitação. Pedidos que não são incidente nem problema: redefinição de senha, concessão de acesso, exportação de dado. Volume alto, complexidade baixa, e é justamente onde automação e autoatendimento rendem mais.

Gestão de configuração. Rastreia os itens que compõem o ambiente: hardware, software, documentação, responsável. Serve para que, na hora do incidente, alguém saiba o que depende do que.

O ITIL, e o que mudou na versão 4

ITIL significa Information Technology Infrastructure Library, biblioteca de infraestrutura de tecnologia da informação.

A sigla começou a ser usada no fim dos anos 1980 pela CCTA, a agência central de computação e telecomunicações do governo britânico, e a série de livros passou a ser publicada a partir de 1989. Depois vieram a versão 2 em 2000, a versão 3 em 2007 e o ITIL 4 em 2019.

Dois pontos de atualização que aparecem errados em muito material em português. O primeiro: o ITIL hoje pertence à PeopleCert, que adquiriu a AXELOS em 2021. A AXELOS era a joint venture criada em 2013 entre o Cabinet Office britânico e a Capita, e é essa a informação que continua circulando. O segundo: o ITIL 3 foi descontinuado em 2022, com suas etapas de ciclo de vida integradas nas práticas do ITIL 4.

O ITIL 4 é onde a conversa com agilidade fica interessante, porque a mudança foi deliberada. Ele incorporou Lean, ágil e DevOps, e a principal alteração de postura foi trocar processo prescritivo por boa prática adaptável, encorajando os times a interpretar em vez de seguir. Junto veio o Sistema de Valor do Serviço, em que oportunidade e demanda entram e valor sai, com princípios orientadores, governança, cadeia de valor, práticas e melhoria contínua.

São 34 práticas, organizadas em três categorias: práticas gerais de gestão, práticas de gestão de serviço e práticas de gestão técnica.

E a mudança mais relevante talvez seja a menos técnica: o foco passou para pessoas e cultura, desencorajando processo pesado, rígido e oneroso.

Os princípios do ITIL 4 ao lado do Manifesto Ágil

Aqui está a evidência mais direta de que a convergência aconteceu de verdade. Vale ler as duas colunas lado a lado.

"Progresso iterativo com feedback" e "mantenha simples e prático" são frases que caberiam sem estranhamento em qualquer material ágil.

Onde isso encosta na realidade

Existe hoje uma certa antipatia pelo ITIL e pelo ITSM, e ela tem origem legítima: a estrutura orientada a processo das versões antigas era pesada. Por causa disso, muitas áreas passaram a promover DevOps como substituto.

Na minha visão, existe sinergia possível entre as estruturas, e foi justamente a versão 4 do ITIL que abriu essa porta.

O que vale lembrar é mais simples que a escolha de framework: entrega de serviço de TI, para cliente interno ou externo, precisa de processo, papel, responsabilidade e métrica. Sem isso, o que existe é boa vontade individual, que funciona até a pessoa certa estar de férias.

O ITSM é particularmente adequado ao fim do ciclo de vida do software, que cada organização chama de um jeito: sustentação, suporte, operação. Ele traz processo claro e documentado, que pode inclusive sustentar contrato de prestação de serviço, dando ao cliente transparência sobre o que está e o que não está no escopo.

Por mais que não seja uma abordagem totalmente ágil, ela tem valor, e eu a uso nos meus projetos.

A decisão de liderança aqui não é escolher um lado. É avaliar o cenário dos serviços prestados e decidir entre ITIL e ITSM, DevOps e ágil, ou os dois em conjunto. O modo híbrido parece complicado no papel, e fica menos quando se lembra que as duas escolas colocam a satisfação de quem usa em primeiro lugar. Elas discordam sobre o caminho, não sobre o destino.

Na sua organização, a operação tem processo e métrica próprios, ou ainda é tratada como a fase final do projeto que ninguém quis planejar?