The Service Level Agreement (SLA)
O Acordo de Nível de Serviço
Recentemente trabalhamos na documentação sobre Service Level Agreement (SLA) ou Acordo de Nível de Serviço. Trata-se de um documento detalhado que define os padrões de um nível de serviço e a relação entre duas partes: solicitador e o executor.
O documento em si é bem complexo na sua elaboração e trata da definição dos seguintes objetivos:
O documento SLA é muito utilizado para abranger uma ampla gama de itens para definição de:
Para elaboração do relatório de SLA entre as partes é necessária uma definição prévia do relatório.
A elaboração do documento não é uma tarefa trivial.
A sua elaboração existem métodos de torná-lo mais amigável. O mais comum é utilizar um modelo pré-definido. O mais conhecido deles é o Toolkit SLA. Esse modelo traduz e identifica o que há de melhor em sua negociação e elaboração.
Por exemplo, existe um “template” (guia) para levá-lo através desta documentação, uma lista de verificação / questionamentos para rever os acordos existentes, bem como uma apresentação de treinamento para exemplificar os conceitos.
O ponto mais crítico do acordo de SLA seria o detalhamento dos serviços e as condições em que esses serviços devem ser entregues. As informações sobre os serviços devem ser precisos e conter especificações detalhadas do que exatamente o que deverá ser entregue.
O documento de SLA, é um documento específico que possue vida própria e versões. Conforme as negociações evoluem, a definição de versões precisa estar bem clara no seu documento. O documento possue revisão e assinaturas entre as partes conforme evolução. O documento não pode ser rígido.
O documento deve constar as seguintes observações:
(a criação de apêndices ajudam a complementar a documentação)
Apêndice A (Informações de contatos)
Nome da Função, Telefone, celular, ….
Apêndice B.
Definições, Termo, Definição, Sigla;
Para um melhor direcionamento das atividades, após as assinaturas da documentação do SLA entre o contratante e contratado, algumas empresas utilizam Gerenciamento de Problemas para minimizar os impactos adversos de incidentes e problemas. Este gerenciamento normalmente especifica o que deve haver um processo adequado para tratar e resolver os incidentes não planejados e que deve haver também a atividade de prevenção para reduzir a ocorrência de incidentes não planejados.
Uma parte essencial de um Service Level Agreement lida com o monitoramento e medição do desempenho de nível de serviço. Essencialmente, cada serviço deve ser capaz de ser medido e os resultados serem analisados e relatados. Os pontos de referência, metas e métricas utilizados devem ser especificados no próprio acordo. O nível de desempenho do serviço deve ser revisto periodicamente pelas duas partes.
É essencial deixar definido nesta documentação para o cliente, que ele também possui as responsabilidades em apoiar o processo de prestação de serviços. O SLA define o “relacionamento” que, naturalmente, é uma troca de informações em duas vias, normalmente, o cliente deve providenciar os acessos, instalações e recursos para que os funcionários da fornecedora trabalhem no local.
Esta seção do acordo de SLA normalmente aborda os seguintes tópicos:
Exclusões;
Força maior;
Segurança; etc.
A segurança é um aspecto particularmente crítico para qualquer SLA. O cliente deve fornecer controle de acesso físico e lógico às suas instalações e informações. Igualmente, o fornecedor deve respeitar e cumprir com as políticas de segurança do cliente e procedimentos.
Esta seção do acordo de SLA normalmente aborda os seguintes tópicos principais:
Denúncia no final do prazo inicial;
Rescisão por conveniência;
Rescisão por justa causa;
Os pagamentos de rescisão
Podemos considerar que as definições de SLA é um documento muito bem aceito entre o prestador de serviços e o contratante. O documento deixa bem claro entre as partes os deveres e responsabilidades. No decorrer do desenvolvimento das atividades, tanto o prestador como o contratante é fundamental não deixar de realizar as reuniões de Gestão de Desempenho e Gerenciamento de Problema. Ambas as atividades trabalham na avaliação constante das atividades da prestação de serviço. Estas atividades tendem a ser o ponto CENTRAL para criação para um SLA sem dificuldades e amigável, pois trata-se de uma “troca” de informações fundamentais para o andamento do contrato. Tentamos colocar neste artigo um “template” de SLA que atendeu as nossas atividades de desenvolvimento um padrão de SLA. Cada instituição deve desenvolver o seu padrão de SLA sendo que o Toolkit SLA será de grande valia para quem deseja iniciar. Procure não ser “rígido” nesta documentação, pois sendo mais flexível, minimizaremos os risco de rescisão, gerando perdas e desgastes para todos envolvidos.
WIKIPEDIA, http://pt.wikipedia.org/wiki/Acordo_de_n%C3%ADvel_de_servi%C3%A7o, acessado em 26/12/2010.
SERVICE LEVEL AGREEMENT AND SLA GUIDE, The SLA Toolkit, http://www.service-level-agreement.net/, acessado em 29/12/2010.
REVISTA ELETRÔNICA, CIO, http://cio.uol.com.br/gestao/2006/06/12/idgnoticia.2006-06-12.4971967799/, acessado em 29/12/2010.
KNOWLEDGELEADER, www.knowledgeleader.com, acessado em 4/01/2011.
You must be logged in to post a comment.
1:43:16 pm
Gostaria de colocar parâmetros em nosso trabalho aqui em nossa Empresa, mas preciso definir números realistas para pequenas médias e grande empresas no sul do país.
6:53:34 am
Interessante o tema e tenho interesse em receber updates sobre o assunto.
9:16:58 am
Acredito que um dos grandes problemas do SLA é criar medições factíveis, indo além do “99,7% de disponibilidade”. Este fator, como outros, é importante, mas muitas vezes é usado de forma preguiçosa, por faltar vontade de identificar e medir os pontos de pressão adequados.
Mais de uma vez, já encontrei com SLAs que se pegavam com a disponibilidade da solução, mas não tocavam em um ponto das entregas da plataforma. Ou seja, tínhamos um SLA que praticamente dizia “contato que o sistema esteja sempre disponível, não precisa entregar os relatórios e análises que me serão úteis”.
Achei muito oportuna a menção à necessidade de registrar o escalonamento, é uma das maiores falhas em qualquer abertura de projeto em TI, não raro relegado à informalidade “se tiver problema, eu falo com o diretor e ele aperta a equipe”.