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).
É 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.
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!
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.
É isso mesmo André. Obrigado pelo comentário adicional!
Abraços!
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.
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!
Obrigado por compartilhar essas regras básicas.
Obrigado por nos acompanhar José!
Abraços
O ANS pode ser colocado em um contrato como garantia do serviço???
Obrigado
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!
Renê, ótimo startup sobre o assunto! vc indicaria alguma obra com uma abordagem prática e com exemplos?
Abs
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!
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.
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
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.
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.
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!
I could’t be bothered to write a new comment
Não entendi. Você não conseguiu postar um comentário?
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
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).
Muito bom na elaboração da minha empresa, parabéns Renê
Valeu Marcel, boa sorte! 🙂
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 ?
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!
Renê, excelente artigo. Você possui detalhes ou melhores práticas de mercado que são utilizadas na definição de SLAs?
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!
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.
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
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?
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! =)
Boa noite Renê,o ANS, seria o mesmo que premissas ou restriçoes do projeto? Obrigado e excelente postagem.
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!
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?
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!
olá,
voce teria algum modelo de SLA ou ANO?
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!
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!!!
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!