Portal GSTI
Portal GSTI

PublicarCadastre-seLogin
Menu
foto de
Fernando Palma

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

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 01)

Qualidade = entrega - expectativa! Esta é a definição que usamos em treinamentos de ITIL V3 para mostrar quanto a expectativa é importante para qualidade na entrega de um serviço de TI . Se a expectativa é maior, ou simplesmente diferente do que é entregue, a equação resultará valor negativo ou inesperado.

Mesmo uma Ferrari não entregará qualidade a seu cliente final se este cliente estiver esperando atingir um objetivo para qual o veículo não se adeque: transporte de cargas, por exemplo, ou percorrer uma trilha num Rally .

Pois bem, um dos principais objetivos do processo de Gerenciamento de Nível de Serviço da biblioteca da ITIL V3 é justamente desenvolver um relacionamento próximo a área de negócio para garantir que a expectativa será bem compreendida e serviços entregues de forma adequada a necessidade. É um processo vital para qualquer provedor de serviços de TI.

Para realizar o que foi descrito acima, o gestor deste processo deve garantir que os requisitos de níveis de serviço sejam definidos, acordados, monitorados, relatados e melhorados continuamente, sempre com foco na necessidade da área de negócio.

Para quem tem pouca intimidade com a Gestão de Nível de Serviços , um Requisito de Nível de Serviço (RNS) é definido pela ITIL V3 como um requisito do cliente em relação a um aspecto de um serviço de TI. O RNS é baseado em objetivos de negócio para definir metas de nível de serviço . A meta de nível de serviço, por usa vez, é um compromisso documentado no Acordo de Nível de Serviço (ANS) com o cliente.

Exemplo de uma meta: "95% dos incidentes solucionados no primeiro nível devem ser finalizados no prazo máximo de trinta minutos".

Se você tem outras dúvidas sobre os conceitos apresentados aqui, recomendo consultar o glossário de termos da ITIL V3 .

Nesta série de artigos, pretendo demonstrar alguns problemas comuns que fazem com que o processo não funcione bem para a organização . A cada publicação, listarei de 03 a 05 falhas. Estando atendo a elas, é mais provável evitar que casos semelhantes ocorram durante a adoção de Gestão de Nível de Serviço baseada na ITIL V3 . Espero que seja útil!

1) Cuidado com a definição de metas que você não pode monitorar.

Existem diversas metas que podem ser definidas e acordadas para serviços de TI. Entretanto, nem sempre é simples acompanhar o desempenho dos serviços para comparar com as metas que foram estabelecidas.

Imagine, por exemplo, a seguinte meta: "O percentual de atendimentos realizados conforme procedimentos internos deve ser superior a 90%." Parece uma meta interessante a ser entregue por um departamento de suporte técnico de TI, mas será que é simples realizar a mensuração do indicador para ser comparado com a meta?

Provavelmente não, pois rastrear estas informações exigirá uma auditoria constante dos passos realizados no atendimento. Acompanhamento que, dificilmente, pode ser automatizada por completo. Portanto, é uma meta interessante de nível de serviço, sim, mas que só deverá ser utilizada caso haja certeza de que você pode mensurar o seu cumprimento.

2) Evite metas de nível de serviço que não entregam valor a sua área de negócio.

Em uma empresa na qual a informação está relacionada a um nível de confidencialidade extremo, é comum que existam diversas metas, no Acordo de Nível de Serviço (ANS) de TI , relacionadas a Segurança da Informação, tais como: critérios de integridade, confidencialidade, número máximo tolerado mensal de incidentes de segurança, metas para continuidade dos serviços, multas previstas na vasão de informação, entre outras. Mas, para uma empresa distinta, nenhuma destas metas pode parecer prioritária.

O mesmo vale para níveis de disponibilidade dos serviços, performance, tempo máximo de solução dos incidentes, tempo médio entre falhas, e muitas outras metas que são comuns em contratos de prestação de serviços de TI. Nada deve ser adotado pela organização e exigido para o serviço sem que exista uma avaliação prévia dos reais Requisitos de Nível de Serviço (RNS) para definição da necessidade de negócio da organização.

Cuidado: entregar uma Ferrari pode custar caro e, ainda por cima, não estar adequado a sua necessidade.

3) Cuidado com a definição de um Acordo de Nível de Serviço (ANS) que não seja suportado por Acordos de Nível Operacional (ANO) e Contratos de Apoio (CA).

É uma falha recorrente a existência de um compromisso entre o provedor se serviços e seu cliente, mas não existirem acordos com equipes internas ( ANO's ) e terceiros ( CA's ) para suportar o primeiro acordo.

Em um exemplo simples, imaginem que uma empresa terceirizada atende um incidente demandado pela área de negócio e deve solucioná-lo em um prazo máximo de 02 horas. Quando o #Service Desk de TI desta empresa realiza o primeiro atendimento, percebe que precisa encaminhar o incidente para uma equipe de segundo nível, formada por profissionais da empresa do próprio cliente.

Quando este encaminhamento ocorre, não existe uma meta que deveria estar formalizada em um Acordo de Nível Operacional (ANO) entre estas equipes: de primeiro e segundo nível.

O que acontece?

É comum que a organização de TI contorne esta situação "pausando" o registro do incidente enquanto está no segundo nível, para que o tempo não comprometa o ANS entregue ao cliente. Resultado: o acordo torna-se fictício. O mesmo ocorre quando existem terceiros envolvidos na prestação do serviço, sem a existência de metas no Contrato de Apoio (CA) .

Se este item 3) não ficou claro para você, recomendo a leitura deste artigo: Service Desk de TI: você está fazendo isso errado.

Nos próximos capítulos desta série, pretendo tratar sobre metas inconsistentes em ANS; metas irreais; sobre a escolha do gestor de nível de serviços; divulgação de metas de ANS; sobre inflexibilidade de ANS; falta de recursos e muito mais.

Conto com a participação de profissionais da área: se você conhece outras falhas recorrentes em na Gestão de Nível de Serviço, cite através de comentários . Compartilhe seu conhecimento com o Portal!

COMPARTILHE

Fernando Palma
Fernando Palma202 Seguidores 574 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