Como este tema funciona na sua empresa
Geralmente escolhem SLA muito simples (uptime apenas) por falta de capacidade de medição. Desafio: insuficiente para governar fornecedor. Abordagem: adicionar 1-2 métricas de relevância prática (tempo de resposta, taxa de erro) usando ferramentas livres de monitoramento.
Começam com múltiplas métricas mas sem critério claro. SLAs podem ser conflitantes ou inatingíveis. Desafio: validar que métricas são apropriadas. Abordagem: processo formal de definição com benchmarks, validação com stakeholders, priorização de 3-5 métricas-chave.
Carteira sofisticada de métricas por serviço. Desafio: manter métricas relevantes e realistas conforme negócio evolui. Abordagem: revisão anual, ajuste dinâmico, integração com OKRs corporativos, rastreamento em dashboards.
Métricas de SLA são indicadores mensuráveis que definem o nível de serviço esperado de um fornecedor, tipicamente incluindo disponibilidade, tempo de resposta, qualidade, e outros KPIs que correlacionam com valor percebido pelo cliente[1].
Por que 65% das métricas de SLA fracassam
Pesquisa Gartner: 65% das métricas de SLA em empresas são inatingíveis ou irrelevantes. Por quê? (1) Baseadas em marketing, não realidade (99,99% porque concorrente tem). (2) Mensurabilidade fraca (não há ferramenta para medir). (3) Influências externas (métrica depende de fatores fora do controle do fornecedor). (4) Falta de validação (nunca perguntaram ao fornecedor se é realista).
Critério SMART para métrica de SLA
Específica: não vaga. "Rápido" é vago; "tempo de resposta <1 hora" é específico. Mensurável: existe ferramenta para medir? Exemplo: uptime é mensurável via monitor; "satisfação do cliente" é vago sem NPS claro. Atingível: baseada em performance histórica. Se fornecedor nunca alcançou 99,99%, SLA não deve ser 99,99%. Relevante: correlaciona com valor percebido. Uptime é relevante; "número de logins" não é. Temporal: período claro. "Uptime ao longo do ano" vs. "uptime medido mensalmente"; segundo é mais rigoroso.
Processo para definir métrica
Passo 1: Entender prioridades. O que importa mais para negócio? Disponibilidade, tempo de resposta, qualidade, custo? Exemplo: e-commerce: uptime crítico. Suporte: tempo de resposta crítico. ERP: qualidade de dados crítica.
Passo 2: Benchmarking. Qual é standard de mercado para tipo de serviço? ITIL define 99,9% para infraestrutura crítica. Validar com benchmarks públicos (Uptime Institute, Forrester, Gartner).
Passo 3: Validar com fornecedor. Propor métrica candidata; perguntar ao fornecedor: é realista? Qual foi sua performance histórica em clientes similares? Se fornecedor diz "impossível", rever métrica. Se diz "sim", usar como validação.
Passo 4: Simplificar. Começar com 3-5 métricas principais; adicionar depois conforme necessidade. Empresas com 3-5 métricas bem-definidas têm 80% mais sucesso em cumprir SLA que as com 10+.
Passo 5: Documentar fórmula. Ser explícito: como é medido uptime? (downtime total / tempo do período) × 100. Como é contado "downtime"? (qualquer interrupção >5 min). Ausência de fórmula clara causa disputa depois.
Usar 1-2 métricas simples: uptime (binário: 100% ou não), tempo de resposta médio. Validação: "oferecedor alcança isso?" Se sim, usar. Ferramenta: ferramentas livres (monit, uptime.com). Revisão: anual simples.
3-5 métricas priorizadas: uptime, tempo de resposta P1/P2, taxa de erro, satisfação. Validação com processo formal (workshop com stakeholders, benchmark). Ferramenta: ITSM comercial. Revisão: semestral com histórico.
Carteira sofisticada por tipo de serviço. Validação contínua. Ferramentas: SIEM/dashboard corporativo. Integração com OKRs. Revisão: trimestral com dados de performance.
Exemplos de métricas viáveis por tipo de serviço
Infraestrutura: (1) Disponibilidade: 99,9% uptime medido mensalmente. (2) Tempo de resposta: latência <100ms em 95% das transações. (3) Throughput: capacidade para 1000 TPS (transações por segundo). (4) RTO: tempo de recuperação <4 horas em caso de falha.
Suporte: (1) Tempo de resposta: P1 <1h, P2 <4h, P3 <24h. (2) Taxa de resolução: 80% dos tickets resolvidos no primeiro contato. (3) Satisfação: NPS >7/10. (4) Disponibilidade: suporte 8-18h weekdays.
Desenvolvimento: (1) Entrega no prazo: 95% dos sprints entregam conforme prometido. (2) Qualidade: <5 bugs críticos por 1000 linhas de código. (3) Performance: aplicação responde em <500ms. (4) Disponibilidade: ambiente em produção 99,9% uptime.
Sinais de que suas métricas de SLA são fracas
Se você se reconhece em três ou mais cenários abaixo, revise métricas.
- Métricas são vagas ("rápido", "bom atendimento")
- Não há ferramenta para medir; validação é manual
- Fornecedor frequentemente falha em SLA; métrica era irrealista
- Métrica depende de fatores externos (ex: receita da empresa) fora do controle de fornecedor
- Não há validação com fornecedor; ele dizia "era impossível"
- Métricas não correlacionam com valor percebido (exemplo: contam algo que ninguém se importa)
Caminhos para definir métricas de SLA
Viável se você tem compreensão do serviço e acesso a dados.
- Perfil necessário: gestor de TI, analista de negócio, fornecedor
- Tempo estimado: 4-6 semanas para desenho e validação
- Faz sentido quando: serviço é bem compreendido, benchmarks estão disponíveis
- Risco principal: métricas ainda irrealistas se não validar com fornecedor
Recomendado para serviços complexos.
- Tipo de fornecedor: consultor de gestão de TI, especialista em SLA
- Vantagem: expertise em métricas, validação com benchmarks, facilitação com fornecedor
- Faz sentido quando: serviço é crítico, você quer confiança nas métricas
- Resultado típico: métricas realistas, validadas, mensuráveis
Precisa definir métricas de SLA realistas para seu fornecedor?
Se você quer desenhar SLAs que funcionam (realistas, mensuráveis, alinhadas ao valor), o oHub conecta você gratuitamente a consultores. Em menos de 3 minutos, descreva seu serviço e receba orientações, sem custo.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe modelo de métricas.
Perguntas frequentes
Quais são as melhores métricas de SLA?
Depende do serviço. Infraestrutura: uptime, latência, throughput. Suporte: tempo de resposta, satisfação. Desenvolvimento: entrega no prazo, qualidade. Escolha conforme valor percebido.
Como escolher métricas SLA realistas?
Validar com fornecedor: qual foi performance histórica em clientes similares? Se fornecedor diz "impossível", rever métrica. Usar benchmarks de mercado (Gartner, Forrester).
SLA deve ser sempre uptime?
Não. Uptime é base, mas adicionar tempo de resposta, qualidade, satisfação conforme tipo de serviço. Exemplo: suporte: tempo de resposta é mais crítico que uptime.
Como evitar SLAs impossíveis de cumprir?
Validar com fornecedor. Usar benchmarks. Começar conservador (5-10% acima de performance histórica), depois ajustar conforme performance melhora.
Qual processo para definir métricas de SLA?
Entender prioridades > Benchmarking > Validar com fornecedor > Simplificar (3-5 métricas) > Documentar fórmula clara.
Como validar que métrica de SLA faz sentido?
Pergunta: fornecedor consegue medir? É atingível? Correlaciona com valor percebido? Se "sim" para todas, métrica é sólida.