Hoje irei falar sobre um item dentro da disciplina de Gestão de Níveis de Serviços (SLM) ainda não muito utilizado pelas empresas, o OLA (Operational Level Agreement, ou Acordo de Nível Operacional).
Muitos de vocês já devem ter vivenciado experiências nas suas empresas onde as áreas de TI são cobradas por providenciar justificativas para as perdas de SLA. Nem sempre essa é uma tarefa fácil, justamente porque um SLA está atrelado a um serviço (fim-a-fim), e geralmente um único serviço possui vários componentes que o suportam, e estes são suportados por áreas distintas da TI.
Para ilustrar, vamos imaginar um serviço baseado em WEB, que possui basicamente:
- A aplicação, suportada pela equipe de Sistemas
- O servidor da aplicação, suportado pela equipe de Sistemas Operacionais
- A rede que conecta o usuário ao sistema (equipamentos de rede, como roteadores, switches,link, cabos, etc), suportados pela equipe de rede externa (fornecedor)
O target de atendimento para incidentes relacionados a este serviço é de 1 hora.
Como na informática cenários ruins podem acontecer (e como!), é possível que o registro de incidente passe por várias áreas, até chegar aquela que realmente vai atuar na solução do incidente, mas quando olhamos o relógio, restam apenas 5 minutos para o SLA estourar e quem acaba sendo penalizado pela perda do SLA é a última área que atuou no incidente. Revoltante não?
Justamente por isso, o OLA deve ser utilizado para definir targets específicos para cada área de TI interna que suporta determinado serviço do negócio – sempre alinhado ao target definido no SLA para atender aquele serviço.
No exemplo acima citado, poderia ser feita uma avaliação dos tipos mais comuns de atuação das áreas em um incidente relacionado ao serviço e prospectar um tempo de atuação para cada área, definindo e acordando um OLA para todas elas (SEMPRE alinhado ao nível de serviço acordado – não adianta um OLA com uma meta que ultrapasse a meta definida no SLA).
Isso é importante para que cada área se preocupe mais em resolver o incidente dentro de sua meta definida em OLA ou, caso a atuação seja de outra área, o chamado seja encaminhado de forma mais rápida para o grupo responsável pela solução do incidente. Dessa forma o SLA não será comprometido e os OBJETIVOS DE NEGÓCIO DA ORGANIZAÇÃO SERÃO CUMPRIDOS.
Além disto, este tipo de acordo pode evitar a famosa frase “este problema não é da minha área, o SLA estourou na área X”.
É preciso que a área de Tecnologia da informação compreenda que ela só existe para atender e implementar o que o cliente REALMENTE PRECISA. Por incrível que pareça, essa cultura dentro das empresas ainda é rara. Quando um SLA é atendido sem o apoio de OLAs e UCs (contratos de apoio ou underpinning contracts)* no final das contas o que acontece é que o serviço de qualidade não é entregue, ou seja, a TI NÃO CUMPRE SEUS OBJETIVOS.
Pense nisso antes de definir ou participar de qualquer SLA!
* Não podemos falar SLAs, sem citar outro nível de serviço que também poderá e deverá suportar esse atendimento – são os contratos de apoio (ou Underpinning contracts – UCs). Neles, serão definidos os níveis de serviço para fornecedores EXTERNOS que também compõem o atendimento de determinado SLA. Mas esse é assunto para outro post…
Loading ...