Portal GSTI
Portal GSTI

PublicarCadastre-seLogin
Menu
foto de
Fernando Palma

Gerenciamento de Nível de Serviço: o que você deve evitar (parte 02)

Precauções que devem ser levadas em consideração no uso de níveis de serviço para gerenciar a qualidade dos serviços de TI (parte 02)


Obs.: este artigo é uma continuação de Gerenciamento de Nível de Serviço: o que você deve evitar (parte 01)
4) Cuidado com metas de Nível de Serviço ambíguas ou pouco detalhadas.
O Acordo de Nível de Serviço (ANS) deve ser claro e consistente (na visão de ambas as partes). Um exemplo de omissão em contratos envolvendo níveis de serviço é a falta de definição clara do que é considerado disponibilidade.

Para entender este aspecto, imaginemos a seguinte situação: um ANS contém uma meta de 99% de disponibilidade para um determinado sistema. Em um dia de segunda-feira, diversos usuários ligam para o #Service Desk reclamando da demora do sistema na execução de funções como exibir um relatório ou mesmo logar.

Na situação descrita acima, a equipe de TI constata que o sistema está demorando cerca de 8 segundos para validar o login do usuário e 12 para exibir o tal relatório, que, em condições normais, era exibido pela aplicação em 02 a 03 segundos, em média.

A pergunta é: neste caso, o Service Desk deve registrar um incidente, caracterizando a indisponibilidade do serviço? O sistema pode ser considerado indisponível por conta de uma demora de 12 segundos para processar uma consulta de um relatório?

Muitos que leem este artigo podem responder: "Claro que não! O sistema está apenas lento e não indisponível." Mas eu faço uma nova pergunta: e se o tempo médio para logar fosse de 8 minutos em vez de 8 segundos; e para processar o relatório fosse de 12 minutos em vez de 12 segundos ? Ainda assim, o sistema seria considerado disponível?

A resposta para esta situação é simples: a performance para o sistema em questão deve estar bem definida por metas dentro do Acordo de Nível de Serviço , ou a situação tornará a operação vulnerável a conflitos entre o suporte de TI e a área de negócio.

5) Sempre que possível, evite metas de nível de serviços aleatórias.

Metas para tempo de solução de incidentes, níveis de disponibilidade e afins não devem ser baseadas em métricas de mercado (se 02 horas está bom para a empresa X, não significa que deve ser bom para mim também).

O nível de qualidade exigido para o serviço deve estar adequado a necessidade de negócio. Cuidado ao replicar contratos de outras empresas ou aceitar sugestões de metas sugeridas por fornecedores e/ou consultores que não conhecem a sua área de negócio.

Para atingir metas de nível de serviço , não basta prometer algo a seu cliente e trabalhar duro para alcançar. As métricas precisam passar por um planejamento e estudo de viabilidade.

Para alcançar um nível de disponibilidade de um serviço, por exemplo, é preciso realizar uma análise das funções vitais, analisar riscos, mitigar riscos, usar técnicas de planejamento da disponibilidade, transformar os requisitos de disponibilidade em ações nos planos da capacidade (passando por requisições de mudança), planejar recursos, orçar custos entre outras medidas descritas na etapa do desenho de serviços da #ITIL .

Sempre que possível, evite oferecer o que você não tem subsídio ainda para planejar. O seu #Service Desk  está preparado para um tempo de reposta médio de 10 minutos? Na dúvida, comece pequeno.

7) Não limite o planejamento de adoção deste processo a gestores e diretoria.
Talvez um dos itens mais importantes desta série: envolva toda a equipe TI o quanto antes.

Em primeiro lugar, como já foi registrado em diversos artigos neste Portal, é preciso lembrar que as pessoas gostam de participar das mudanças organizacionais ativamente em vez de serem obrigadas a mudar.

É importante perceber também o quanto a adoção de níveis de serviço impacta na rotina das pessoas. O profissional de atendimento e suporte pode encarar as metas de níveis de serviço simplesmente como procedimentos chatos que funcionam para pressionar o técnico a atender rapidamente as demandas. Isso me lembra uma vez que eu escutei de um técnico que "uma equipe competente não precisa de SLA *".

Por isso, a equipe precisa entender exatamente o que são os níveis de serviço: não significa atender incidentes rapidamente e sim estudar e entregar a verdadeira necessidade da área de negócio.

*SLA : Service Level Agreement (Acordo de Nível de Serviço).

COMPARTILHE

Fernando Palma
Fernando Palma196 Seguidores 573 Publicações Consultor de TI, CEO
Seguir
Sou fundador e CEO do Portal GSTI, Consultor, professor e instrutor em Governança de TI e Gestão TI. Graduado em SI, mestrando em administração, Certificado ITIL Expert, ITIL Manager, COBIT, OCEB, ISO 20k, e ISO 27k.

Comentários