Um dos aspetos em que as empresas mais falham à hora de fazer contratos de Tecnologias de Informação (TI) é o dos níveis de serviço, habitualmente conhecidos por SLA (Service Level Agreements). As principais razões para esta falha prendem-se, por um lado, com a própria definição dos SLA e, por outro, com a respetiva aplicação de penalizações por incumprimento dos mesmos. Analisaremos as quatro situações que levam a contratos de TI frágeis, frente aos grandes fornecedores de TI.

SLA inexistentes

Muitos contratos de compra de software, em modelos on-prem ou SaaS (Software as a Service), bem como os contratos de manutenção que lhes estão associados, por incrível que possa parecer, não preveem SLA. Ou seja, em termos de prazos, nem os fornecedores de software nem os fornecedores de serviços terão qualquer compromisso concreto de resolução de incidentes, atualizações (sejam técnicas, sejam funcionais), ou pedidos de correção ou evolução.

No fundo, é isto que acaba por acontecer com muitos fornecedores de utilities ou de telecomunicações, para o público em geral. O que as pessoas se limitam a fazer em caso de avarias que conduzem a cortes de fornecimentos é queixar-se, dizer que os fornecedores são incompetentes, ou que não deviam ser pagos pelos períodos de “corte”, ou outras coisas mais que podem fazer bem à alma, mas a pouco mais.

Ora, é precisamente para evitar estes tipos de comportamentos, que têm tanto de emocionais como de ineficazes, que as empresas (pelo menos as que queiram ser profissionais) deverão prever SLA nos seus contratos.

SLA ineficazes

Naturalmente, há empresas que já superaram o tema da inexistência de SLA. Outras, hesitam ainda entre tê-los (muitas vezes num anexo longínquo) ou não os ter verdadeiramente, enchendo as cláusulas do contrato base com expressões, em relação à “obrigação” de prazos de resposta, reação e resolução, que acabam por criar folgas para os seus fornecedores de IT: “na medida do possível”, “atuando de forma diligente”, “em tempo razoável”, “sempre que razoavelmente exequível”, “empregando os melhores esforços” ou mesmo “sujeito a limitações técnicas ou operacionais” … Isto retira, naturalmente, eficácia ao anexo dos SLA!

Outra “artimanha”, muito vista, que retira eficácia aos SLA é as empresas de TI apenas assumirem compromissos de tempos de resposta, reação, mas não de resolução. Fazendo a analogia com as urgências de um hospital, o tempo de resposta seria aquele que tardam em atender-nos, o tempo de reação o que passa até sermos chamados para a triagem… e nada mais. Ou seja, o tempo de resolução, que é aquele que demoram a resolver-nos o problema que nos levou às urgências, não contaria! Através da analogia parece ridículo, certo? Mas peçam lá dois ou três contratos de TI que tenham SLA e vejam se contempla tempos de resposta, isto é, de resolução definitiva dos chamados “tickets”.

Finalmente, a ineficácia por derivar de se fixarem SLA para certos temas, mas não para outros (ficando este sem SLA). Por exemplo, um contrato de SaaS pode contemplar os seguintes SLA, que indicaremos aqui de forma muito resumida:

  • Disponibilidade e Performance – O tempo que o software está disponível e a sua rapidez/fiabilidade de funcionamento;
  • Suporte Técnico – Quem está “do outro lado da linha” para atender os utilizadores e os seus pedidos (os habituais serviços 24×7);
  • Manutenção e upgrades – Gestão do ciclo de vida do software, incluindo as novas versões, updates, patches …
  • Business Continuity e Disaster Recovery – Todas as operações que visam a recuperação do software em caso de ocorrência de um “desastre” (externo ou interno). Aqui assumem particular relevância os SLA de RTO (Recovery Time Objective) e RPO (Recovery Point Objective): o primeiro indica o tempo máximo para o sistema voltar a estar ativo; enquanto o segundo mede o tempo máximo de dados que estamos dispostos a perder;
  • Evolução Funcional – Neste caso não se trata da evolução técnica do software, mas antes das (novas) funcionalidades que o mesmo deverá disponibilizar aos utilizadores;
  • Compliance Funcional – Enquanto a Evolução Funcional está mais dependente dos pedidos da própria empresa para fazer face às suas necessidades de negócio, o Compliance Funcional visa manter o software atualizado em função de todas as alterações legais ou regulatórias que ocorrem ao longo do tempo.

Prevermos apenas um certo tipo de SLA não nos protegerá contra necessidades ocorridas em outros.

Penalizações inexistentes

SLA sem penalizações são como leis penais sem molduras penais. A quem passaria pela cabeça fazer leis penais sem molduras penais? Pois é, infelizmente, a muitas empresas. Se alguém fizesse a pergunta sobre se houve mais contratos de TI por falta de SLA ou por falta de penalizações, eu tenderia a dizer que há mais sem penalizações. No entanto, ambos são igualmente “inúteis”. Assim sendo, deverão as empresas associar penalizações aos SLA não cumpridos, classificando os incumprimentos segundo a sua gravidade: baixa, média, grave ou crítico. Normalmente, a gravidade mede-se pela conjugação entre impacto (n.º de utilizadores afetados) vs. urgência (função da tolerância ao erro: por exemplo, um sistema de faturação de um supermercado tem de estar “sempre” ativo). Conclusão: não esquecer as penalizações, normalmente percentagens dos valores pagos aos fornecedores, que deverão ser tanto maiores quanto mais graves.

Penalizações ineficazes

Finalmente, vem o tipo de astúcia de fornecedor de TI mais difícil de detetar, e que nos foi matematicamente ilustrado por uma pessoa da área de TI de um cliente nosso do setor financeiro: o SLA que nunca se incumpre, e, por isso, ao qual nunca se aplicam penalizações. Como acontece este “buraco”? Pois é simples: ter um software parado 10 minutos por dia pode causar um prejuízo brutal a certo tipo de processo que o mesmo integra, em certos tipos de setores nos quais as empresas se integram. No entanto, se a métrica for mensal, como o é habitualmente, o sistema pode ter tipo 30 dias de interrupções de 10 minutos e não se aplicar qualquer penalização.

Como? Vamos fazer os cálculos: 30 dias têm 720 horas e, consequentemente, 43.200 minutos. 300 minutos a dividir por 43.200 minutos aproximadamente 0,7%. Ou seja, mesmo que o nível de serviço assegurado pela empresa de TI fosse 99%, não se aplicaria qualquer penalização, apesar das 30 paragens diárias de 10 minutos! Claro que as empresas podem contornar esta previsão. Mas então que a contornem, incluindo as ocorrências diárias, as repetições, etc.

Para terminar, e para proteger eventos ineficácias das penalizações, lembremo-nos da importância da responsabilidade que poderá ter o fornecedor de TI de indemnizar o seu cliente, caso lhe cause prejuízos. Aqui o único conselho a dar é evitar a todo o custo que tal apenas possa ocorrer caso o fornecedor de TI tenha agido com maldade, culpa, dolo e, até mesmo, negligência grosseira. Lutem pela mera “negligência” ou, se tiverem que aceitar a “negligência grosseira” para retirar limites de indemnização e/ou suportar prejuízos indiretos por parte do fornecedor de TI, dobrem (aumentem) a previsão dos montantes a indemnizar.