fbpx

Blog HDI

Artigos, notícias e pesquisas

Você precisa melhorar seus SLAs?

Você precisa melhorar seus SLAs?

Sua organização de TI documentou e assinou acordos de nível de serviço (SLAs) com os principais gerentes e stakeholders de sua empresa? Em caso afirmativo, seus SLAs fornecem algum valor para sua empresa? Como você sabe?

Como você sabe que seus SLAs estão REALMENTE gerando valor para sua empresa?

Tudo sobre um SLA

Um SLA é um acordo interno entre um provedor de serviços (TI) e seus clientes. Nesse contexto, um cliente é a pessoa ou grupo que define a necessidade de um serviço e paga por ele. Um bom SLA oferece benefícios mútuos para a organização de TI e para o negócio que atende, pois descreve a relação entre o que a TI faz para o sucesso dos negócios, por meio do uso de tecnologia.

Os componentes básicos de um SLA são:

  • Descrição do serviço. Qual é o serviço e como ele entrega ou auxilia nos resultados do negócio?
  • Como o “valor” será medido. Valor é uma percepção. Entender o que a empresa considera valioso e como esse valor deve ser medido é algo fundamental.
  • Metas de desempenho acordadas mutuamente. Quais são (determine algumas) as metas de desempenho que a organização de TI deve atingir para conseguir a satisfação do cliente?
  • Frequência, formato, audiência e conteúdo dos relatórios de desempenho. TI deve relatar quão bom é seu desempenho na entrega dos serviços descritos no SLA – seja ele bom ou ruim. Se a TI não mantiver (e fazer relatórios) de pontuação de desempenho, nem ela, nem o cliente serão capazes de saber como o serviço está sendo desempenhado.
  • A frequência e os participantes das Revisões de Nível de Serviços (SLR). SLRs regulares são um fator crítico para o sucesso com SLAs.

Considerações para definir SLAs

Definir e destacar os SLAs pode ser bom para a organização de TI e para os negócios que ela atende. Bons SLAs são propícios para conversas e compreensão mútua sobre o uso da tecnologia dentro de uma empresa, bem como para permitir que ocorra uma melhoria contínua. Mas muitas organizações estabelecem SLAs sem pensar neles a fundo. Antes de começar a definir um SLA, aqui estão algumas perguntas a serem consideradas:

  • Você realmente precisa de um SLA? Os SLAs, quando bem definidos, exigem um nível de esforço tanto dos colegas de trabalho quanto da organização de TI para que seja possível colher os benefícios. Qual é o orientador dos negócios para desenvolver os SLAs?
  • Quem será responsável pelo SLA? Para ser eficiente, o SLA deve ser responsabilidade tanto dos negócios quanto da organização de TI, uma vez que nenhum deles pode ter sucesso com o uso do SLA sem a participação do outro. Em outras palavras, não ter um responsável significa que ninguém se importa com ele.
  • Você tem as pessoas certas envolvidas na definição de um SLA? Se as pessoas que assinam o SLA não possuem nenhuma influência sobre o uso e percepção do serviço, você não tem a equipe certa envolvida.

Mas isso não é tudo. Há outros pontos a considerar:

  • SLAs não são SLAs, a menos que estejam documentados e assinados. Eu encontrei muitas organizações que afirmavam ter SLAs, quando tudo o que fizeram foi definir algumas configurações em uma ferramenta de ITSM. O que essas organizações têm são SLGs – Adivinhações de Nível de Serviço. Não há nada mutuamente acordado, documentado e assinado. É só adivinhar o que será medido e relatar.
  • SLAs que ficam somente nas prateleiras são inúteis. Em minha experiência, esse é o resultado quando alguém risca “definir SLAs” de sua lista de tarefas. Não houve entendimento ou acordo para o uso do SLA; era apenas algo que precisava ser feito, como uma obrigação.
  • SLAs não são armas para combater os clientes. Eu já vi várias organizações de TI dizendo aos seus clientes que “isso não está no SLA” ou “já atingimos nosso SLA”. Isso é, frequentemente, um indicativo de um SLA que não reflete com precisão a necessidade dos negócios. E isso certamente também não reflete uma atitude adequada orientada para os serviços.
  • SLAs não podem ter a abordagem “pronto e acabou”. As necessidades de negócios e os recursos de TI estão sempre mudando e evoluindo. Portanto, para que um SLA seja eficiente, ele não pode ter uma definição de “escrever uma vez e esquecer pelo resto da vida”, mas deve ser revisado e atualizado regularmente.

Suas metas de SLA estão desgastadas e irrelevantes?

Talvez a consideração mais importante ao definir SLAs seja identificar metas e medidas relevantes para os negócios. Muitos esforços no estabelecimento de SLAs são insuficientes, porque as medidas referenciadas não têm significado algum para os negócios. Por exemplo, “número de chamadas ao service desk” é importante para que o gerente do centro de suporte possa ter um entendimento e acompanhamento da situação. Mas, do ponto de vista comercial, o service desk está lá para receber chamadas; é por isso que ele existe. Como minha chamada para o service desk resulta em valor comercial? Ou ainda, vamos pegar o exemplo da velocidade média de resposta (ASA). Novamente, essa métrica é boa para o gerente do centro de suporte. Mas, se minha ligação para a central de atendimento demora 60 segundos para obter uma resposta, ao invés da média de 25 segundos, tudo o que isso resultará será na minha irritação. Não me importa que minha experiência em particular tenha sido uma exceção.

Se esses tipos de medidas operacionais que você relata fizerem parte dos seus SLAs, precisará melhorar os mesmos. Seus SLAs podem e devem ser muito mais do que simplesmente capturar métricas e produzir relatórios que não tenham relevância comercial e que ninguém lê.

Como você pode melhorar seus SLAs? Que tal utilizar uma estrutura estratégica?

Introduzindo a estrutura estratégica

Uma estrutura estratégica é um método estruturado, usado para definir como um projeto ou uma iniciativa apoia os principais objetivos dos stakeholders. A base para a estrutura estratégica é a declaração de missão, visão e objetivos da empresa.

Então, como a estrutura estratégica pode ajudar você a elevar seus SLAs? Primeiro, a estrutura estratégica auxilia no entendimento dos principais objetivos dos stakeholders. Na perspectiva de um SLA, eles são principalmente clientes (conforme definido anteriormente). Qual meta de negócios o cliente está tentando atingir através do uso de um serviço de TI? Aumentar as vendas em 25% em dois anos? Introduzir dois novos produtos até o final do ano? Ou talvez, seja aumentar a participação de mercado em 40% em 3 anos. Independentemente disso, a primeira etapa para elevar seu SLA usando a estrutura estratégica é entender as metas dos negócios.

A próxima etapa é identificar como esse serviço de TI ajuda a empresa a atingir suas metas de negócios. O que o serviço de TI fornece ou permite que a empresa utilize para atingir tais metas? Usando os exemplos acima, quais resultados fornecidos por um serviço de TI ajudarão a empresa a aumentar as vendas, introduzir novos produtos ou aumentar a participação de mercado? No contexto da estrutura estratégica, esses resultados se tornam seus objetivos. No contexto de um SLA, esses resultados são a base para suas metas de nível de serviço.

E como esses resultados podem ser medidos para que sejam significativos para o negócio? Por exemplo, em vez de relatar a disponibilidade do serviço (por exemplo, 98% de disponibilidade), que tal relatar uma medida relevante para o negócio que reflete a disponibilidade (por exemplo, TI forneceu disponibilidade suficiente para que a empresa superasse sua meta de produzir mais de 1000 itens pelo terceiro mês consecutivo)? O primeiro exemplo – 98% – tem pouco significado para o negócio. Mas os negócios podem se identificar imediatamente com a segunda medida: mais de 1000 itens produzidos por três meses consecutivos.

Pense em Termos de Negócios

O uso da estrutura estratégica como guia para o desenvolvimento de SLAs auxilia TI a pensar em termos de negócios, não em termos de tecnologia ou atividades. A definição dos SLAs a partir dessa perspectiva mudará a percepção de que TI é um “executor de pedidos” para um “parceiro e recurso valioso” para os negócios que atende. 

*Doug Tedder é um professional de gerenciamento de serviços de TI estratégico, inovador e orientado a soluções, com mais de 20 anos de experiência em diversas indústrias. Ele é um líder talentoso e prático, com um histórico de sucesso na implementação de processos de governança de ITSM e TI. Doug é um ITIL Expert e ISO/IEC 20000 Consultant Manager certificado, além de possuir diversas outras certificações da indústria. Além disso, Doug é um treinador credenciado da ITIL Fundation e um instrutor para Analista do Centro de Suporte e Gerente do Centro de Suporte do HDI. Siga o Doug no Twitter e conecte-se com ele no LinkedIn.


Imprimir   Email

Entre em contato com o HDI

Siga o HDI Brasil