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:
- Identificar e definir as necessidades do cliente;
- Proporcionar uma melhor compreensão dos objetivos do serviço;
- Simplificar o entendimento do serviço;
- Reduzir as áreas de conflito;
- Incentivar diálogo em caso de litígios
- Eliminar as expectativas não compatíveis com o serviço especificado.
O documento SLA é muito utilizado para abranger uma ampla gama de itens para definição de:
- Desempenho;
- Controle e relatórios de Gerenciamento de Problemas;
- Conformidade Legal;
- Resolução de Conflitos;
- Deveres e Responsabilidades do Cliente;
- Segurança;
- Direitos de propriedade intelectual e informações confidenciais;
- Rescisão Contratual.
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.
ELABORAÇÃO DE UM SLA
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.
EXEMPLO DE UMA DOCUMENTAÇÃO DE SLA
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:
- 1 – Histórico;
Definir o histórico da revisão, data, descrição do serviço e revisão do autor. - 2 – Aprovações (quem deve aprovar);
Nome, Data, Título, assinatura e e-mail. - 3 – Âmbito (inserir informação descrevendo o escopo do documento);
- 3.1 Audiência (inserir informação descrevendo o público adequado para o documento);
- 3.2 Finalidade (inserir informação descrevendo a finalidade do documento);
- 3.3 Pressupostos (inserir informações que descrevem os pressupostos associados ao documento);
- 3.4 Contatos (inserir informações que descrevem os contatos associados ao documento). Caso haja necessidade criar um Apêndice para obter detalhes adicionais de contato.
- 4 – Garantias e recomendações e Detalhamento do Serviço;
- 4.1 Formatos de arquivo (inserir informações que descrevem os formatos de arquivo exigido pelo documento);
- 4.2 Entregas e Expectativas Arquivo;
- Tipo de Arquivo, freqüência esperada / Freqüência Mínima chegada na Empresa X, o mais tardar: Método de transporte (FTP / Manual Drop Arquivo)
- 4.3 Ações de escalonamento (inserir informações que descrevem as ações escalada exigido pelo presente documento)
- 4.4 Recursos para escalonamento (inserir informações que descrevem os recursos de escalonamento exigidos pelo presente documento)
- 4.5 Horas de serviço para resolução de problemas (inserir informação descrevendo as horas de serviço disponível para resolver problemas)
- 4.6 Desenvolvimento arquivo (inserir informações que descrevem o processo de desenvolvimento de arquivo requerido por este documento)
- 5 – Gerenciamento de Problemas;
- 6 – Gestão de Desempenho;
- 7 – Deveres e Responsabilidades do Cliente;
- 8 – Rescisão
(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;
GERENCIAMENTO DE PROBLEMAS
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.
GESTÃO DE DESEMPENHO
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.
DEVERES E RESPONSABILIDADES DO CLIENTE
É 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.
GARANTIAS E RECOMENDAÇÕES
Esta seção do acordo de SLA normalmente aborda os seguintes tópicos:
- A qualidade do serviço;
- Indenizações;
- Recomendações e violações:
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.
RESCISÃO
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
CONCLUSÃ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.
REFERÊNCIA BIBLIOGRÁFICA
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.
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.
Interessante o tema e tenho interesse em receber updates sobre o assunto.
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”.