O que são KPIs no ITIL
"Um KPI (Key Performance Indicator) é uma métrica quantificável que mede o desempenho de uma actividade, processo ou serviço em relação a um objectivo definido."
No contexto do ITIL, existe uma distinção importante entre métricas e KPIs. Uma métrica é qualquer medição - o número de tickets abertos, o tempo de resposta, o volume de chamadas. Um KPI é uma métrica associada a um objectivo específico que serve para avaliar se esse objectivo está a ser cumprido. O número de tickets abertos é uma métrica. A percentagem de tickets resolvidos no primeiro contacto, quando o objectivo é superar 75%, é um KPI.
O ITIL introduz também o conceito de CSF (Critical Success Factor). Os CSFs definem o que deve correr bem para que um processo ou serviço tenha sucesso. Os KPIs medem o progresso em direcção a esses CSFs. Por exemplo, o CSF pode ser "Resolver incidentes rapidamente" e o KPI correspondente será "Tempo médio de resolução inferior a 4 horas". O CSF define a condição de sucesso; o KPI mede se essa condição está a ser cumprida.
Esta distinção evita um problema comum: organizações que medem tudo sem saber por que medem. Um KPI sem um CSF por trás é simplesmente uma métrica decorativa. Antes de definir qualquer KPI, a pergunta a fazer é sempre: "Que condição de sucesso este indicador está a medir?"
KPIs do service desk
O service desk é o ponto de contacto entre os utilizadores e a equipa de TI. Os seus KPIs medem a eficiência do atendimento, a qualidade da resolução e a satisfação dos utilizadores. Os benchmarks apresentados são baseados em dados da MetricNet e do HDI (Help Desk Institute).
| KPI | Descrição | Benchmark |
|---|---|---|
| First Contact Resolution (FCR) | % de pedidos resolvidos no primeiro contacto, sem necessidade de escalonamento ou follow-up | 74% média (MetricNet) |
| Tempo médio de resolução (MTTR) | Horas médias desde a abertura do ticket até à resolução completa | 8,85 horas (MetricNet) |
| Satisfação do cliente (CSAT) | Pontuação de satisfação do utilizador, recolhida por inquérito após resolução | 80-90% (HDI) |
| Custo por ticket | Custo médio de tratamento de cada ticket, incluindo recursos humanos e tecnologia | Varia por organização |
| Taxa de abandono | % de chamadas ou contactos abandonados antes de serem atendidos por um técnico | < 5% |
| Tickets por analista | Volume de tickets tratados por técnico por mês - indicador de produtividade e carga de trabalho | 400-600 por mês |
O FCR é frequentemente considerado o KPI mais importante do service desk porque reflecte tanto a eficiência da equipa como a qualidade da base de conhecimento disponível. Um FCR baixo indica que os técnicos de primeiro nível precisam de mais formação, que a base de conhecimento está desactualizada, ou que os processos de escalonamento estão mal definidos.
KPIs de gestão de incidentes
A gestão de incidentes tem como objectivo restaurar o serviço normal o mais rapidamente possível após uma interrupção. Os seus KPIs reflectem a velocidade de resposta, a conformidade com os SLAs acordados e a qualidade da resolução.
| KPI | Descrição | Benchmark |
|---|---|---|
| MTTR (Mean Time to Resolve) | Tempo médio desde a abertura do incidente até à resolução e fecho | Varia por prioridade |
| MTTA (Mean Time to Acknowledge) | Tempo médio desde a detecção ou reporte até ao reconhecimento formal do incidente | < 15 min (P1) |
| Volume de incidentes | Número total de incidentes por período - a tendência descendente é o objectivo | Tendência descendente |
| Conformidade com SLA | % de incidentes resolvidos dentro dos tempos definidos no SLA, por categoria de prioridade | > 90% |
| Incidentes reabertos | % de incidentes reabertos após fecho - indica problemas de qualidade na resolução | < 5% |
| Incidentes por categoria | Distribuição por tipo de incidente - essencial para identificar padrões e alimentar a gestão de problemas | - |
Os incidentes são normalmente classificados por prioridade (P1, P2, P3, P4) e os KPIs de conformidade com SLA devem ser medidos separadamente para cada prioridade. Um P1 (impacto crítico) tem tempos muito mais curtos do que um P4 (impacto reduzido). Agregar todos os incidentes num único KPI de conformidade pode esconder problemas graves nos incidentes de alta prioridade.
KPIs de gestão de problemas
A gestão de problemas tem um objectivo diferente da gestão de incidentes: não resolve interrupções imediatas, mas investiga as causas raiz para prevenir a recorrência. Os seus KPIs reflectem a maturidade do processo de análise e a eficácia na redução de incidentes repetidos.
| KPI | Descrição | Benchmark |
|---|---|---|
| Erros conhecidos documentados | Número de known errors registados na base de dados de erros conhecidos (KEDB) | Tendência crescente |
| Redução de incidentes recorrentes | % de diminuição de incidentes repetidos associados a problemas conhecidos | > 10% por trimestre |
| Taxa de conclusão de RCA | % de problemas com análise de causa raiz completa e documentada | > 80% |
| Tempo médio de resolução de problemas | Dias desde a identificação do problema até à resolução permanente da causa raiz | Varia por complexidade |
| Workarounds disponíveis | % de problemas abertos que têm um workaround documentado para mitigar o impacto nos utilizadores | > 70% |
Um indicador de maturidade da gestão de problemas é a relação entre o volume de incidentes e o número de problemas identificados. Organizações com processos reactivos têm muitos incidentes e poucos problemas registados. Organizações maduras identificam problemas proactivamente, antes que causem incidentes, através de análise de tendências e análise de causa raiz sistemática.
KPIs de gestão de mudanças
A gestão de mudanças equilibra a necessidade de implementar melhorias com o risco de introduzir novas falhas. Os KPIs medem tanto a velocidade de implementação como a qualidade - uma mudança rápida que causa um incidente não é um sucesso.
| KPI | Descrição | Benchmark |
|---|---|---|
| Taxa de sucesso de mudanças | % de mudanças implementadas sem falha nem rollback, dentro do âmbito e prazo definidos | 90-97% (mudanças normais) |
| Mudanças de emergência | % do total de mudanças que são classificadas como emergência - um valor elevado indica problemas no planeamento | < 10% |
| Lead time de mudanças | Tempo desde o pedido de mudança até à implementação - medido por tipo de mudança | Varia por tipo |
| Mudanças que causam incidentes | % de mudanças que resultam num incidente após implementação - indicador crítico de qualidade | < 5% |
| Backlog de mudanças | Número de mudanças pendentes de aprovação ou implementação - um backlog crescente indica gargalo no processo | Tendência estável |
A percentagem de mudanças de emergência é um KPI particularmente revelador. Quando ultrapassa os 10%, indica que a organização não está a planear adequadamente as mudanças - está sempre a reagir a situações de urgência em vez de gerir proactivamente o seu portfólio de mudanças. Isso tem impacto directo na taxa de sucesso, porque mudanças de emergência têm menos testes e revisão.
KPIs de disponibilidade e SLA
A disponibilidade dos serviços é frequentemente o KPI mais visível para o negócio. É medida em percentagem e expressa em "nines" - o número de noves na percentagem de disponibilidade. A tabela abaixo mostra o impacto real de cada nível de disponibilidade em termos de downtime anual e mensal.
Para além da disponibilidade percentual, a gestão de disponibilidade acompanha outros indicadores fundamentais que medem o comportamento do serviço em caso de falha e a capacidade de recuperação.
| KPI | Descrição | Benchmark |
|---|---|---|
| MTBF (Mean Time Between Failures) | Tempo médio entre falhas consecutivas de um serviço - quanto maior, mais fiável o serviço | Tendência crescente |
| MTRS (Mean Time to Restore Service) | Tempo médio para restaurar o serviço após uma falha - quanto menor, mais ágil a recuperação | Tendência decrescente |
| Conformidade com SLA | % de serviços que atingiram os níveis de disponibilidade acordados no SLA no período em análise | > 95% |
| Taxa de violação de SLA | Número de incumprimentos dos níveis de serviço acordados por período - cada violação deve ter análise de causa | Tendência decrescente |
A relação entre MTBF e MTRS define a disponibilidade efectiva de um serviço. Um serviço com MTBF elevado (falha raramente) e MTRS baixo (recupera rapidamente quando falha) tem disponibilidade elevada. Melhorar apenas um dos dois tem impacto limitado - é necessário trabalhar os dois em simultâneo, através da gestão de disponibilidade e da gestão de incidentes.
Como definir bons KPIs
A maioria das organizações não tem falta de dados - tem excesso de métricas sem objectivo. Definir bons KPIs começa por aplicar o critério SMART a cada indicador que se pretende adoptar.
O critério SMART aplicado a KPIs
S - Específico (Specific)
O KPI mede algo concreto e bem definido. "Melhorar o suporte" não é específico. "Aumentar o FCR para 78% no service desk de Lisboa" é específico.
M - Mensurável (Measurable)
Pode ser quantificado com dados objectivos e replicáveis. Se a medição depende da interpretação de quem mede, não é um bom KPI.
A - Atingível (Achievable)
O objectivo é realista com os recursos disponíveis. Um target de 99,999% de disponibilidade para um serviço sem redundância é inatingível e desmotivante.
R - Relevante (Relevant)
Alinha-se com os objectivos de negócio. Um KPI de "número de relatórios gerados" é irrelevante se o negócio precisa de velocidade de resolução de incidentes.
T - Temporal (Time-bound)
Tem um prazo definido para avaliação. Um KPI sem horizonte temporal não permite gestão por objectivos nem comparação entre períodos.
Erros comuns na definição de KPIs
Ter 50 KPIs é o mesmo que não ter nenhum. Quando tudo é prioritário, nada é prioritário. O foco recomendado é entre 5 e 7 KPIs por prática - os que realmente reflectem o que mais importa para o negócio.
Um KPI sem target definido é apenas uma métrica. Medir o MTTR sem definir um valor-alvo não permite saber se o resultado é bom ou mau. Definir sempre o valor-alvo antes de começar a medir.
Comparar KPIs entre organizações sem considerar diferenças de dimensão, sector ou maturidade é enganoso. Os benchmarks são uma referência, não um mandato. O ponto de partida certo é o histórico da própria organização.
Focar só em velocidade e custo, ignorando a qualidade e a satisfação do cliente, leva a optimizações que prejudicam o serviço. Uma organização que fecha tickets rapidamente mas sem os resolver correctamente terá MTTR baixo e CSAT baixo ao mesmo tempo.
Descarregue a template de relatório de entrega de serviço
Modelo profissional para reportar KPIs, SLA compliance e melhorias, em formato Word.
Ver todas as templates ITSMQuer medir o que realmente importa?
Na formação ITIL 4 Foundation, aprende a definir KPIs, CSFs e a medir o desempenho dos serviços de TI.
Ver formação ITILPerguntas frequentes
Uma métrica é qualquer medição quantitativa (ex: número de tickets). Um KPI é uma métrica associada a um objectivo específico que indica o desempenho de um processo crítico (ex: FCR > 75%). Nem toda a métrica é um KPI, mas todo o KPI é uma métrica. A diferença está na ligação a um objectivo concreto.
Entre 5 e 7 KPIs por prática é o recomendado. Demasiados KPIs diluem o foco e tornam a monitorização impraticável. Equipas com 20 ou 30 KPIs tendem a não actuar sobre nenhum deles porque não conseguem determinar prioridades. Escolha os que melhor reflectem os objectivos de negócio e reveja a lista regularmente.
MTTR (Mean Time to Resolve) é o tempo médio de resolução de incidentes. Calcula-se somando o tempo total de resolução de todos os incidentes num período e dividindo pelo número de incidentes nesse período. Por exemplo: 10 incidentes com tempos de resolução que somam 88,5 horas resultam num MTTR de 8,85 horas. Segundo a MetricNet, a média global para service desks é precisamente 8,85 horas.
CSFs (Critical Success Factors) são as condições que devem estar reunidas para que um processo ou serviço tenha sucesso. Os KPIs medem o progresso em direcção a esses CSFs. Exemplo: CSF = "Alta satisfação do utilizador"; KPI = "CSAT > 85%". Os CSFs definem o que deve correr bem; os KPIs confirmam se está efectivamente a correr bem.
Depende do tipo de KPI. Métricas operacionais como volume de tickets ou MTTR devem ser monitorizadas diariamente ou semanalmente para permitir acção rápida. KPIs estratégicos como satisfação do cliente ou custo por ticket podem ser revistos mensalmente ou trimestralmente. O importante é ter ciclos de revisão definidos e actuar sobre os desvios detectados, não apenas registá-los.
Os benchmarks servem como referência, não como objectivo absoluto. Cada organização tem contexto próprio: dimensão, sector, complexidade tecnológica, nível de maturidade dos processos. Um service desk de 5 técnicos numa PME terá naturalmente indicadores diferentes de um service desk de 200 técnicos numa multinacional. Use benchmarks para identificar desvios significativos e estabelecer metas realistas, não para copiar números de outras realidades.