Muitos profissionais de suporte responderiam com uma única palavra:
TUDO!
Às vezes, isso pode certamente parecer dessa maneira. E, se não houver definição da expectativa de forma adequada, sem um contrato negociado entre você e seus clientes/usuários finais, detalhando quais os serviços que prestamos e as condições em que você os fornece, é justamente dar a oportunidade para que as pessoas pensem que você suporta “tudo”.
Um Service Level Agreement (SLA) é exatamente isso: um contrato, negociado por você e seus clientes, que lista o que você (suporte), seus padrões para concessão de suporte, como você mede a eficácia do suporte e os direitos e responsabilidades de seus clientes. Você acumula diversos benefícios através da implementação de um programa de SLA, tais como:
· Você e seus clientes têm expectativas claramente definidas.
· Cada grupo tem suas responsabilidades documentadas.
· O relacionamento com seus clientes é reforçado através do processo de deseonvolvimento do SLA.
· Seus clientes ficam melhor informados sobre a relação entre o nível de suporte prestado e seu custo.
· A sua equipe fica melhor instruída sobre a relação entre a falta de suporte e seu efeito sobre os seus clientes
· Você tem uma situação que permita a discussão sobre a melhoria dos serviços.
· Você tem o início de um processo de melhoria contínua.
É um conceito simples, com muitos benefícios, mas muitas vezes as tentativas de implementar um programa de SLA falha miseravelmente. Por que isso? Geralmente, é porque o SLA não está totalmente definido.
Vamos dar uma olhada no que você precisa para escrever um bom SLA Nunca se esqueça que é um Acordo de Nível de Serviço.
O processo de elaboração de bons acordos de nível de serviço começa com seus clientes.
Você e seus clientes desenvolvem o SLA juntos e concordam com o conteúdo. Reunir uma equipe interdepartamental para a construção do SLA tem benefícios como o aprofundamento da compreensão do negócio dos seus clientes e a melhor compreensão do trabalho do suporte pelos clientes.
Um bom SLA é curto.
Vimos documentos SLAs de mais de 40 páginas, com detalhes excruciantes, com as minúcias de suportar aplicações específicas. O acordo em si não deve ser superior a 10 páginas (se isso!), embora você possa colocar adendos com uma lista dos aplicativos e hardware suportados.
SLAs têm um escopo definido.
Há certamente coisas que você não suporta, ou momentos que certos serviços não estão disponíveis. Mas seus clientes podem não saber disso. A seção de escopo do SLA define o horário de funcionamento, os métodos pelos quais você pode ser contatado e uma noção geral do “Menu de serviços” que você pode oferecer. Se a lista de hardware e software é bastante resumida, ela pode ser incluída aqui, caso contrário, a lista de hardware e aplicações padrões suportados de devem ser colocados em um adendo.
Você também deve incluir qualquer coisa que não suporte, para prevenir que seus clientes deduzam que tudo o que não está especificado também seja suportado. Por exemplo, se você não fornece suporte a PDAs pessoais, isso deve estar discriminado no escopo.
Um bom SLA é simples.
Você não deve precisar de um doutorado para lê-lo! Um SLA contém os objetivos de nível de serviço, ou SLOs, e as normas específicas de um serviço que está sendo garantido aos seus clientes. Por exemplo, você pode ter um SLO que ateste: “novos usuários receberão seus equipamentos e acesso às aplicações em não mais de três dias úteis após a apresentação do pedido de novo usuário”. Este SLO centra-se em uma necessidade da empresa – a necessidade de obter novos usuários em produção rapidamente. Baseie seus SLOs em termos que sejam significativos para o negócio e reflitam reais necessidades do negócio, e não linguagem técnica.
Você pode obter um salto no processo de construção de SLA revendo os dados de pesquisa de satisfação do cliente: quais são as questões que mais mexem mais com os seus clientes?
Todos os seus clientes devem ser capazes de compreender facilmente o SLA e ver como se relaciona com as suas atividades comerciais. Se você inevitavelmente tem que usar terminologias técnicas, inclua uma espécie de glossário, com os significados.
As expectativas dos seus clientes incluem mais do que apenas os motivos pelos quais podem contatar o suporte. Eles também têm expectativas sobre a quantidade de tempo que vai levar para ajudá-los, quanto tempo levará para retornar uma chamada e com que freqüência você atualizará o status do chamado. Certifique-se que estes aspectos estejam incluídos dentro seus SLOs.
SLOs são viáveis.
O exemplo de SLO acima é pouco viável, se você não mantiver um depósito de hardware e levar três semanas para receber novos equipamentos de seus fornecedores! Isso nos leva a uma componente extremamente importante de qualquer programa de SLA: a avaliação. Antes de colocar um SLA para rodar, você necessita determinar o que é realista para o seu departamento. Um SLO que diz que você vai atender todas as chamadas dentro de 30 segundos não faz sentido se o seu histórico mostra que 60 segundos é o melhor que você já foi capaz de prover. Uma vez que você e seus clientes tenham identificado os SLOs necessários, examine o seu desempenho nessas áreas. Enquanto você e seus clientes podem não gostar de algumas das respostas no início, você não se comprometerá com metas inatingíveis. E se o desempenho realista não alcançar as expectativas do negócio, você tem um argumento para pedir recursos adicionais para suportar seus clientes!
E não é apenas o seu próprio desempenho que você precisa avaliar. Seu departamento de suporte depende de fornecedores, outros departamentos de TI e várias outras áreas dentro e fora da empresa. Você precisa da compreensão do que pode esperar de grupos que apoiarão seus esforços para suportar os seus clientes. Isso mesmo, você precisa de SLAs com seus grupos de apoio.
Geralmente, os SLAs externos são definidos nos contratos com seu fornecedores. Os SLAs internos do departamento de TI são geralmente muito menos formais do que os SLAs desenvolvidos com os seus clientes. Muitas vezes, na verdade, os “SLAs” são inerentes aos caminhos que o serviço terá de trilhar. Independentemente de como você opta por definir suas expectativas com seus grupos de apoio, você deve ter um entendimento deles antes de fazer quaisquer promessas aos seus clientes.
SLOs são mensuráveis.
Um SLA é inútil se ninguém pode dizer se ou não os seus objetivos são sendo atendidas. Você deve ser capaz de medir e informar sobre cada um dos seus objetivos definidos. Isso pode exigir um pouco de trabalho braçal: você tem relatórios, ou você pode desenvolvê-los a fim de determinar a velocidade média de resposta? Ou o tempo de preparação de novos usuários? E todos os seus outros objetivos?
A maioria das operações de suporte relata no SLA objetivos mensais ou semanais. Os relatórios, assim como os objetivos, devem falar às necessidades do negócio e ser de fácil compreensão. Gráficos são uma boa escolha, se a informação puder ser disponibilizada dessa forma. Esteja preparado para abordar exceções e circunstâncias especiais em seus relatórios.
Relatar que o Departamento de Finanças não teve interrupções de serviço em 99% do tempo é inútil, para dizer o mínimo, quando o 1% ocorrer durante o período de fechamento financeiro.
Claro, você não pode reportar sobre qualquer coisas que você não captura. Para que o seu programa de SLA seja eficaz, você deve registrar todas as chamadas. Isso pode exigir novas políticas e normas dentro de seu grupo antes da implementação do SLA.
A medição componente de um SLA tem outra implicação: a sua equipe de suporte deve ter os recursos disponíveis para realizar a medição. Os SLAs exigem constante atenção, e muitos grupos não consideram a quantidade de trabalho envolvido antes de embarcar em um programa de SLA. Olhe o que você se comprometeu a medir e atribua a tarefa a uma pessoa ou algumas e, em seguida, analise se esse recurso terá o tempo para realizá-la.
SLAs têm penalidades.
O que acontece se você não entregar o que prometeu? Sem multas, seus clientes não terão nenhuma garantia real de que você têm um incentivo a realizar seu trabalho ao nível definido.
Fornecedores externos geralmente têm penalidades. Os departamentos internos que usam um sistema de estorno podem usar esse método, mas e os grupos internos de apoio que não fazem cobranças? Muitas vezes, exigir do departamento de suporte às reuniões para discutir o fracasso de não cumprimento dos padrões de serviço, pode funcionar como uma “penalidade”.
Em tal reunião, os membros da equipe de suporte têm a oportunidade de falar sobre as causas de falhas de qualquer serviço e os membros do negócio podem certificar-se que o departamento de suporte tem um plano eficaz para prevenir que essas falhas não se repitam.
Os caminhos de escalações muitas vezes são incluídos nesta seção (ou às vezes em uma seção separada) a fim de dar ao cliente uma forma de chegar a um responsável, caso o serviço não seja prestado dentro dos prazos especificados.
SLAs são documentos vivos.
Você não pode simplesmente escrever um SLA e arquivá-lo. Seu SLA deve valer por um período de tempo específico, com a revisão e renovação sendo feita ao final desse período. Se manuseado corretamente, um SLA é a pedra fundamental de um programa de melhoria contínua, e você deve certificar-se de que o desempenho de melhorias se reflita cada vez que o SLA é renegociado.
A ação de mensurar tem um efeito colateral interessante. Estudos têm mostrado que, quando o desempenho é medido, o desempenho começa a melhorar, independentemente de quaisquer outras medidas que sejam tomadas para melhorar especificamente o desempenho. Parte disso tem a ver com a atenção adicional da administração em relação a elementos de desempenho;
o resto tem a ver com o desejo humano de competir!
Isso não significa que o SLA deva ser revisto apenas no final do período de tempo definido.
Cada relatório que você produz em na realização dos SLOs é uma oportunidade para rever o seu desempenho. Você está em um ponto onde pode garantir um serviço ainda melhor aos seus clientes? Ou, são áreas que apesar de seus esforços na avaliação, você constantemente não cumpre os níveis de serviço prometidos? Um SLA deve incluir a possibilidade de mudança dentro de seu ciclo de vida, bem como no seu final. Uma mudança muito simples no processo de controle permite modificações no SLA quando você ou seus clientes exigirem.
Seu SLA também precisa mudar quando novas aplicações, projetos, serviços ou hardware são disponibilizados aos seus clientes. Isto é simplesmente uma boa prática comercial, mas muitas empresas só pensam na equipe de suporte após o fato – um programa de suporte SLA pode colocá-lo na vanguarda na mente das pessoas e assegura o envolvimento do seu grupo no planejamento de novas iniciativas.
Ele prevê uma situação ganha-ganha.
Um SLA não é um documento que existe apenas para formalizar uma forma de acusação de erro. Você e seu cliente precisam entrar em um processo de negociação com o desejo comum de criar um contrato que contenha serviços úteis e padrões alcançáveis de desempenho, que estejam relacionados com objetivos de negócio. Se você e seus clientes estão apenas buscando uma forma de punir outra parte, a implementação de SLA falhará.
Um SLA é a pedra fundamental de um programa de melhoria contínua!
Para resumir: quais são as características de um bom SLA?
É um acordo.
Você e seus clientes a constroem o SLA juntos e concordam com seu conteúdo.
É curto.
Não se empolgue com a sua eloqüência. Você quer um documento que as pessoas usem como guia com freqüência e não arquivem e esqueça.
Ele tem um escopo definido.
Afinal, você provavelmente não vai querer apoiar tudo!
É simples, e ele fala sobre o negócio, não tecnologia. Se o seu cliente não consegue entender exatamente o que está escrito, você precisa uma reescrevê-lo.
É viável.
Se você sabe que não pode fazer algo, ele não deve estar lá. E, se você não tiver certeza, é necessário descobrir antes da implementação do SLA.
É mensurável.
Todos os seus SLOs precisam ser mensuráveis e você precisa estar com os relatórios de desempenho prontos.
Ele inclui penalidades.
Um SLA sem “penalidades” não é um SLA real.
Ele define um processo de mudança.
Sua empresa está em constante evolução e os SLA precisam refletir isso.
É o resultado de uma vitória para você e seus clientes!
Depois de ter um rascunho de seu primeiro SLA e teste-o. Todos a contemplação, análise e avaliação que você fez na configuração objetivos podem desmoronar no mundo real. Então não implique o seu SLA a todos os seus clientes de uma só vez. Escolha um grupo simpático de testes, que lhe dará um feedback honesto, propiciando melhorias.
Como você deve ter percebido, há muito mais para um programa de SLA do que apenas o os próprios Acordos de Níveis de Serviço. Um simples documento escrito não irá corrigir as deficiências dos serviços, ou magicamente fazer seus clientes felizes. Um SLA é nada mais nada menos do que o símbolo de empenho do seu departamento em melhorar continuamente o serviço e uma atitude centrada no cliente.
Chris Broome
É um parceiro do The Diagonal Group, um empresa de consultoria e suporte que fornece soluções perspicazes, objetivas e úteis que ajudam as empresas a fazer parte integrante do serviço de seus negócios. Você pode encontrar um modelo de SLA no site do The Diagonal Group.
www.thediagonalgroup.com/downloads/SLA_template.htm , e pode contatar o Chris
pelo e-mail chris@thediagonalgroup.com
.: Encontro de utilidades :. 