André Iizuka: Os 7 pecados capitais do SLA

No momento, você está visualizando André Iizuka: Os 7 pecados capitais do SLA

Indefinições de aspectos como níveis de serviços, prazo, aspectos trabalhistas e penalidades estão entre os principais problemas

André Iizuka

03/09/2012 às 7h30

Foto: https://computerworld.com.br/acervo/os-7-pecados-capitais-do-sla/

O tema é o calcanhar de aquiles de muitas organizações. Com início na década de 80, por meio das empresas de telefonia, o Acordo de Nível de Serviço (ANS ou SLA, do inglês Service Level Agreement), espalhou-se chegando ao setor de TI. Hoje, presente em todo o mercado, podemos defini-lo como um acordo firmado entre a área de TI e o cliente interno, que descreve o serviço de tecnologia, suas metas de nível de serviço, além dos papéis e responsabilidades das partes envolvidas no acordo.

Contudo, a busca das organizações ainda permeia pela excelência do SLA, já que erros comuns ainda hoje possibilitam que as empresas percam quantias incalculáveis, por falta de planejamento básico, legal e técnico como, por exemplo, destacar os serviços imprescindíveis ao negócio, determinar em contrato quanto tempo é possível ficar sem eles, ou quanto tempo é, ao menos aceitável, sem que o negócio seja prejudicado.

De acordo com a norma brasileira ABNT NBR ISO/IEC 20000-1:2011, esse documento deve ser acordado entre os requisitantes ou interessados em um determinado serviço de TI e o responsável pelos serviços de TI da organização. O mesmo deve ser revisado periodicamente para certificar de que continua adequado ao atendimento das necessidades de negócio da organização.

Na atual versão da biblioteca ITIL (versão 3), o ANS insere-se no contexto dos processos de Desenho de Serviço (Service Design), especificamente no processo Service Level Management, ou Gerenciamento de Nível de Serviço (SLM). O SLM envolve a negociação, o acordo e a apropriada documentação de níveis de serviço que atendam às necessidades do negócio, permitindo a entrega de serviços de TI com a qualidade e tempo esperados.

Considerando que para determinar o que é crítico pode variar de um usuário para outro, a visão nesse caso deve ser sempre a do negócio. Parâmetros como a interrupção de faturamento, vendas, serviços sob força legal e até mesmo o número de usuários afetados devem ser estabelecidos. Quanto mais crítico para a missão do negócio, mais exigente será o nível de SLA. De forma geral, é preciso ficar atento a alguns aspectos, entre eles, alguns pecados mais comuns:

–  Referir-se ao contrato firmado entre a organização e o seu fornecedor externo de TI como um ANS. O correto é o Contrato de Apoio (do inglês Underpinning Contract), que também pode e deve envolver a definição de níveis de serviço, mas não configura um ANS propriamente dito, entretanto no mercado de tecnologia e com o outsourcing da maioria dos departamentos de TI de grandes empresas predominou o termo como Contrato de ANS;

– Confundir prazo de atendimento de um suporte técnico com prazo de resposta e de resolução.  A maioria dos usuários de tecnologia entende que a cláusula de prazo de atendimento é um SLA;

3 – Tratar o SLA como um serviço padrão da empresa, e não um serviço especial ou excepcional de acordo com as necessidades do cliente com preços e condições diferenciadas. Nem sempre o contratante ou usuário de tecnologia necessita de um atendimento ou de resolução VIP. Somente os que têm em sua operação níveis de criticidade elevados é que tem necessidade de um padrão elevado de atendimento e de resolução. Por exemplo: sistemas de aeroportos,  portos, bancários, hospitais, segurança nacional, militar, entre outros;

4 – Falta de definição dos níveis de serviços (modo ou forma) com o estabelecimento de Key Performance Indicators (KPI) adequados, tangíveis e aceitáveis tanto para o prestador de serviços de TI como para o usuário final;

5 – Falta de definição específica das penalidades e contrapartidas específicas para o descumprimento das obrigações constantes no SLA, o que pode levar para a vala comum dos processos judiciais de indenização ou mesmo da rescisão contratual por justa causa. É importante deixar bem definido e combinado que tipo de reparação ou compensação o cliente ou o usuário da tecnologia pode esperar das empresas de TI. Como se sabe, inexiste sistema, plataforma, infraestrutura, software ou serviços infalíveis, e nesse sentido nenhuma garantia pode ser conferida a isto. Por essa razão,  propõe-se as formas de contingenciamento por meio do SLA;

6 – Eleger as isenções de responsabilidade em casos que estão fora do controle do prestador de TI, tais como queda de energia, dolo ou culpa dos funcionários da contratante ou de fornecedores, falta de peças de reposição, entre outros;

7 – Falta de preparo interno da empresa de TI para propor esse tipo de serviço especial ou excepcional. A maioria das empresas tem oferecido suporte 24 x 7 x 365, porém deixa à disposição o número de celular ou redireciona o telefone de suporte técnico para um funcionário ou colaborador da empresa em caso de necessidade ou pane no sistema. Ocorre que ao deixar de tomar as contramedidas em relação à responsabilidade da empresa quanto aos encargos trabalhistas dessa “disposição” para o usuário final pode gerar problemas. Vale formalizar um acordo de compensação de horas adequado para evitar violação das leis trabalhistas. 

É certo que a maioria das empresas de TI confia tanto nos sistemas ou na infraestrutura, inclusive de contingência que deixam de atentar para problemas em relação ao atendimento e à performance do ANS.

São inúmeros os detalhes efetivos que devem ser analisados nesses contratos para evitar prejuízos e desgastes com o cliente, e para que haja um ciclo de vida do contrato mais perene, além de promover parcerias de longo prazo entre o cliente final e as empresas de TI.    

*André Iizuka  é especialista no segmento de Tecnologia da Informação e Telecomunicações, sócio da Iizuka Advocacia e Pesquisador do Grupo de Estudos de Tributação Internacional (GETI-NEF) do Núcleo de Estudos Fiscais da Escola de Direito de São Paulo da Fundação Getúlio Vargas – NEF/DireitoGV.

COMPUTERWORLD usa cookies para personalizar conteúdo e anúncios, para melhorar sua experiência em nosso site. Ao continuar, você aceitará o uso. Para mais detalhes veja nossa Política de Privacidade.