fbpx
5 passos para definir um bom Acordo de Nível de Serviço (SLA)

Conceitos

5 passos para definir um bom Acordo de Nível de Serviço (SLA)

Renê Chiari
Escrito por Renê Chiari em 29 de junho de 2016
Junte-se a mais de 24.900 pessoas

Entre para nossa lista e receba conteúdos exclusivos e com prioridade

Apesar do SLA (Service Level Agreement) ter se tornado um jargão bastante conhecido e utilizado, é comum encontrar documentos mal escritos, com falta de informações e definições confusas até para o próprio provedor de serviços.

Isso não é bom nem para o provedor, e nem para o cliente, pois dá margem para discussões que podem comprometer o bom relacionamento entre as partes, e em casos mais graves até causar uma rescisão contratual (no caso de provedores de serviço externos) ou a decisão pelo outsourcing (no cado de provedores de serviço internos).

SLA
Acordo de Nível de Serviço

É preciso entender que um acordo de nível de serviço é muito mais do que um documento descrevendo prazos de atendimento e resolução de chamados.

Trata-se de um acordo que deve deixar claro todas as garantias que o provedor de serviço oferece em relação aos serviços que foram contratados, e a forma como estes níveis de serviço serão medidos, reportados e melhorados continuamente.

Para resumir: o (bem) combinado não sai caro!

Se você nunca desenvolveu um SLA ou acha que o utilizado atualmente na sua empresa precisa de ajustes, responder as seguintes perguntas é um bom começo.

 

Pergunta 1: O que?

Qual o serviço que está sendo objeto deste acordo? Contextualizar o serviço já no primeiro capítulo é uma boa pedida. Aqui também pode-se fazer referência ao Catálogo de Serviços.

Considere as exclusões, que são as situações em que este acordo de nível de serviço não é aplicável. Isto evita uma série de aborrecimentos futuros.

Um dos assuntos mais comumente esquecidos é o “Stop SLA” (ou pausa no SLA), onde são considerados os períodos em que os casos estão sob tratamento de suporte do próprio cliente, ou seja, o provedor de TI não deveria assumir o ônus por este período de tempo.

 

Pergunta 2: Quando?

Quando o serviço deve ser fornecido? Deveria ser incluído  no mínimo, o percentual de disponibilidade do serviço, o horário do serviço (período em que deve estar disponível, por exemplo: em horário comercial, 24×7, etc), o horário do suporte ao serviço (Service Desk por exemplo).

Também é muito importante incluir as condições de exceção, como feriados, finais de semana, etc.

 

Pergunta 3: Quanto?

Esta pergunta não tem relação com valor a ser pago pelo serviço, que normalmente já é definido no Catálogo de Serviços, e sim em qual quantidade e com qual desempenho o serviço será entregue. Ou seja, requisitos de capacidade.

Pode-se incluir por exemplo: taxas de resposta, número máximo de transações simultâneas, usuários concorrentes, etc.

Outra boa sacada é considerar “lotes” e “franquias” de requisições de serviços. Por exemplo: considerar um lote máximo de requisições simultâneas do tipo X.

Caso a quantidade ultrapasse o limite, será necessário uma mudança (que exige aprovação e um projeto associado). Em outros casos é possível acordar cobrança adicional quando a franquia de requisições for atingida, como forma de influenciar o comportamento dos usuários.Service Level Agreement

 

Pergunta 4: Como?

Talvez este seja o capítulo mais extenso, e com direito a incluir alguns tópicos:

Papeis e responsabilidades

Uma boa prestação de serviço exige que não somente o provedor, mas também o cliente, cumpram alguns deveres. Se engana quem acha que o cliente (e os usuários) não têm responsabilidades.

Suporte ao Cliente

Neste tópico, algumas informações importantes como os possíveis canais de contato do cliente com o Service Desk, os tempos de resposta para cada tipo de caso, de acordo com os critérios de priorização, matriz de escalonamento, etc, podem ser incluídas.

Reporte e análise crítica do serviço

A maioria dos Acordos de Nível de Serviço não deixam claro a periodicidade e a forma como os níveis de serviço serão medidos, reportados,  analisados criticamente junto ao Cliente e continuamente melhorados. Este momento é uma excelente oportunidade não só para identificar os pontos falhos na entrega de serviços, mas também oportunidades de novos negócios. Vale lembrar que este item é, inclusive, um requisito da norma ISO/IEC 200000.

Canal de Reclamação

Seja lá qual for o nome mais adequado: ombudsman, ouvidoria, etc. O importante é mencionar um canal onde o cliente possa reclamar caso não esteja satisfeito com o serviço, e garantir que será dado um tratamento adequado a esta reclamação.

Pergunta 5: E se der $%@&… ??

Como dizem os americanos: “coisas” acontecem…

O provedor deve estar preparado para imprevistos de grande magnitude. O Acordo de Nível de Serviço (SLA) pode deixar claro para o Cliente a existência de um plano de continuidade, ou considerações que evidenciem que o provedor gerencia os riscos de seus serviços, endereçando respostas adequadas para cada um deles.

Ao ler este artigo, definir um Acordo de Nível de Serviço pode parecer fácil mas está longe disso. Estes são apenas alguns dos ingredientes básicos de uma atividade que leva tempo, e muita discussão.

Aproveite para explorar mais sobre este tema lendo esse outro artigo sobre SLA, sobre a ITIL e sobre o framework COBIT.

Abraços e até a próxima!

TAGS: SLA

Opa,

o que você achou deste conteúdo? Conte nos comentários.

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

40 Replies to “5 passos para definir um bom Acordo de Nível de Serviço (SLA)”

André Bernardo de Oliveira

Excelente.

Fora que uma definição de SLA mal planejada aumenta o risco para o provedor, o que acarreta em custo, que é revertido para o preço que você está pagando pelo serviço.

Renê Chiari

É isso mesmo André. Obrigado pelo comentário adicional!

Abraços!

Emerson Dorow

Olá Renê,
Muito interessante seu artigo. Escrever um contrato de SLA em si é simples, o difícil é você não deixar nenhuma “perninha” de fora. Isto pode dar muita dor de cabeça.

Estas suas orientação são bem importantes.

Parabéns.

Emerson.

Renê Chiari

Olá Emerson, você tem toda razão. O documento em si não é tão difícil, o problema é na hora de “combinar o jogo”.

Mas por incrível que pareça, ainda vejo SLAs bastante mal escritos que lá na frente (quando o serviço entra em operação) geram grandes dores de cabeça.

Abraço e obrigado pelos comentários!

Renê Chiari

Obrigado por nos acompanhar José!

Abraços

Carlos

O ANS pode ser colocado em um contrato como garantia do serviço???
Obrigado

Renê Chiari

Olá Carlos,

Não só pode, como deveria. recomendo fortemente que em qualquer contrato seja incluído um ANS como anexo, detalhando os níveis de serviço acordados.

Abraços e obrigado por nos acompanhar!

Sidney Rodrigues

Renê, ótimo startup sobre o assunto! vc indicaria alguma obra com uma abordagem prática e com exemplos?
Abs

renechiari

Olá Sidney, obrigado pelo feedback.

Como sempre, indico a própria publicação “Service Design” da biblioteca ITIL como uma rica fonte de informações. Além disso também indico as publicações da Van Haren – http://www.vanharen.us/

Abraços!

Willams

Os Sla’s devem ser muito bem acordados entre cliente e fornecedor, todos os pontos devem ser vistos e as criticidades devem estar alinhadas com a realidade do projeto, os prazos também devem estar bem definidos para que não haja o não cumprimento dos mesmos.

wady

Boa noite Rêne estou no 4° ano de administração e meu Tcc será sobre Sla será que o Sr teria algum material para nos ajudar a formatar esse grande desafio?
Somos da Faculdade São Bernardo / FASB

aguardo seu Retorno
Muito Obrigado

rafael neris

Rene, como fica um SLA para um serviço hospedado fora do Brasil, pois tem a questão de fuso horário, como posso criar um documento com essas questão.Pois a minha aplicação vai depender da funcionalidade de um provedor que esta em outra região.

rafael neris

Rene, como fica um SLA para um serviço hospedado fora do Brasil, pois tem a questão de fuso horário, como posso criar um documento com essas questão.Pois a minha aplicação vai depender da funcionalidade de um provedor que esta em outra região.

Renê Chiari

Olá Rafael, desculpe a demora em responder.

No seu caso, a regra continua a mesma. Basta considerar o fuso horário nos termos do SLA (GMT). Normalmente (não sei se é o caso) os provedores possuem atendimento ‘follow the sun’.

Abraços!

rafael neris

I could’t be bothered to write a new comment

Renê Chiari

Não entendi. Você não conseguiu postar um comentário?

Retrospectiva 2014 - ITSM na Prática

[…] 5 Passos para definir um SLA […]

Lucas

Boa noite,

Renê, o ANS se aplica em áreas de mesma empresa? Se sim, como se daria esta aplicação.

exemplos: operacional X suprimentos, financeiro X vendas, etc

aguardo seu retorno.

grato

Renê Chiari

Olá Lucas, boa noite.

O conceito de ANS se aplica sim entre áreas da mesma empresa, por exemplo projetos X operação, Service Desk X áreas de suporte especializado, TI X suprimentos ,etc. A única diferença é que este acordo tem um outro nome. É chamado de Acordo de Nível Operacional (ANO).

Marcel

Muito bom na elaboração da minha empresa, parabéns Renê

Renê Chiari

Valeu Marcel, boa sorte! 🙂

Gerenciamento De Projetos Software Garden Design | Actual Percentil

[…] ITIL na Prática | Como definir um SLA? Conheça 5 passos … – É preciso entender que um acordo de nível de serviço é muito mais do que um documento descrevendo prazos de atendimento e resolução de chamados…. […]

Sergio Mitter

Olá Rene, tenho uma pergunta.
E se acontecer de perder o SLA. Qual o procedimento normal ? ou seja, que processo devemos seguir ? e Quem envolver ?

Renê Chiari

Olá Sergio,

O SLA deve contemplar, inclusive, o que será feito caso houver o rompimento de um ou mais níveis de serviço. Existem SLAs que preveem multas, descontos na fatura e outros tipos de penalizações. Eu já vi alguns casos (raros) onde o SLA prevê bonificações ao provedor de serviço caso os níveis de serviços sejam cumpridos durante um período de tempo.

O mais importante é combinar esta variável do jogo também. Espero ter ajudado.

Grande abraço!

Kendson

Renê, excelente artigo. Você possui detalhes ou melhores práticas de mercado que são utilizadas na definição de SLAs?

Renê Chiari

Olá Kendson, muito obrigado pelo feedback.

Tenho algumas indicações de materiais mais detalhados:

– Livro ITIL Service Design (especificamente o capítulo Service Level Management). Só existem versões em inglês.
eBook: Service Agreements – A Management Guide (english version)
– Infelizmente não existem publicações nem materiais práticos e em português. Tenho planos de criar isso em breve. Se possível poste suas principais dificuldades com relação a esse tema.

Grande abraço!

murilo Alencar

Parabéns pelo artigo,gostaria de saber como funciona a SLA no help service,com todos os seus detalhes pois não consigo achar nada relacionado.

Renê Chiari

Olá Murilo. obrigado pelo comentário.

O SLA pode ser aplicado em vários contextos, inclusive no de um Service Desk. Uma dica é você procurar pelos livros da Van Haren. Eles tem muitos títulos bons sobre ITSM. Pretendo escrever mais sobre este tema em breve. Abraços

Renan Oliveira

Boa tarde, Renê.

Trabalho em uma instituição que está implantando uma Central de Serviços de TI. Estamos na fase de definição dos acordos operacionais e de serviços.

Gostaria de saber se o correto seria definir os SLAs de cada serviço oferecido presente catálogo, ou referente a cada setor existente na organização? Inicialmente pensamos em Definir os SLAs para Setores prioritários ou não. Seria correto fazer isso?

Renê Chiari

Renan, tudo bem? As duas abordagens estão ‘corretas’ (na ITIL são conhecidos como SLA baseado no cliente e SLA baseado no serviço). Vocês precisam identificar qual delas faz mais sentido. Quanto menor o número de SLAs que consigam cobrir a maior parte dos clientes/serviços , mais fácil gerencia-los! =)

5 passos para definir um bom acordo de nível de serviços - Strati

[…] Aqui no site ITSM na Prática tem um artigo bem bacana com os 5 passos para definir um bom acordo de nível de serviços. […]

Carlos Augusto

Boa noite Renê,o ANS, seria o mesmo que premissas ou restriçoes do projeto? Obrigado e excelente postagem.

Renê Chiari

Olá Carlos, o ANS pode incluir, mas não está restrito, apenas à premissas e restrições. Por exemplo, você pode incluir em um ANS uma restrição de número de requisições de serviço solicitadas em um período mensal, sob a possibilidade de cobrança adicional caso esse limite seja ultrapassado. Uma premissa poderia ser que todas as mudanças na infraestrutura que o cliente fizer por conta precisam ser notificadas para o provedor de serviços (mesmo que não haja o envolvimento operacional dele).

A comparação é válida porém é importante ter em mente que o ANS não substitui um plano de projeto. Normalmente o ANS é desenhado durante o projeto (o que normalmente associamos com a fase de desenho de serviço) e passa a vigorar ao término do projeto (final da fase de transição de serviço e inicial da fase de operação de serviço).

Abraços e obrigado pelo comentário!

Alex

Olá Renê, excelente artigo.

Tenho uma dúvida:

o SLA incia-se no momento da abertura do chamado ou quando o mesmo é iniciada a execução por parte do técnico?

Renê Chiari

Olá Alex, tudo bem? O SLA deve ser iniciado no momento da abertura do chamado, em outras palavras, a partir do momento em que o cliente tem um serviço indisponível ou uma requisição que precisa ser cumprida pelo provedor de serviço.

O tempo em que os grupos de suporte específicos atuam sobre o chamado podem ser controlados através de OLAs (Operational Level Agreements, ou Acordos de Nível Operacional) e devem sempre estar alinhados com o SLA.

Abraço!

CARLOS

olá,
voce teria algum modelo de SLA ou ANO?

Renê Chiari

Olá Carlos, você encontra vários modelos distintos no Google. Talvez por isso que não publiquei um template. Prefiro ajuda-los a criarem o seu próprio modelo. De qualquer maneira, sugiro que você ‘deposite sua sugestão’ na fábrica de conteúdos aqui do blog.

Segue o link: https://feedback.userreport.com/9074d413-c1bf-4295-8590-91817bcb3ceb/

Abraços!

Eduardo

Boa tarde Renê! Tudo bem?

Seu artigo está ótimo! Instrutivo e esclarecedor! Admito que quando li sobre o “Stop SLA” trouxe um certo alívio para mim, visto que depender de alguma informação ausente por parte do solicitante do chamado e a SLA continuar “correndo” é muito preocupante, podendo acarretar no próprio “estouro” da SLA sujando a imagem da empresa. E saber que podemos pausar a SLA é tranquilizador, principalmente em meu cenário onde possuímos tanto clientes internos quanto externos.

Mas tenho uma pergunta a fazer quanto a isso! Quando acionamos o recurso para pausar a SLA até o retorno do solicitante, como esse pause deve funcionar? Digamos que a SLA para o serviço seja de 72 horas e precisamos de uma informação crucial do solicitante quando faltam 60 horas e pausamos a SLA. A SLA volta a contar no momento que o solicitante realizar um novo comentário no chamado a partir das 60 horas restantes? Mesmo que esse comentário ocorra 2-3 semanas depois?

Forte abraço e obrigado pelos excelentes artigos mais uma vez!!!

Renê Chiari

Olá Eduardo, tudo bem? Desculpa a demora na resposta.

Em tese, vc retorna a contabilizar o SLA mediante o retorno da pendência do usuário. Mas o bom senso precisa ser colocado em prática. Uma requisição com mais de 2-3 semanas sem o retorno do usuário talvez não seja tão importante. Talvez ele tenha errado na solicitação. Talvez tenha se desligado da empresa, etc. É bom combinar uma política (sempre com o aceite do cliente e documentado em SLA) de um prazo máximo para resposta, sob a possibilidade do mesmo ser encerrado por falta de retorno do usuário.
As ferramentas mais sofisticadas de gestão permitem que se crie um workflow automatizado e que seja necessário preencher campos específicos ou enviar informações obrigatórias antes da configuração da abertura do chamado. Isso também ajuda a reduzir esse tipo de situação.
Abraço e obrigado por acompanhar o blog!

Sobre

Rene A. Chiari Tecnologia da Informação ME / ITSM na Prática.

Av. Melchert, 37 – Chácara Seis de Outubro – São Paulo/SP.

CNPJ: 25.072.324/0001-66

Todos os direitos reservados. Termos de uso.

 

Fale Conosco

contato@itsmnapratica.com.br