DevSecOpsARTIGO

Transfira o Risco para Longe de TI

As áreas de tecnologia da informação normalmente assumem riscos desnecessários devido à ausência de instrumentos para transferir ou compartilhar riscos com outras áreas. O desconhecimento desses processos e do conceito de risco aumenta o custo operacional e diminui a qualidade do serviço, pois necessitam administrar um estoque sempre crescente de problemas potenciais.

Risco é a possibilidade da ocorrência de eventos que causem perdas ou flutuações em receitas futuras. É tudo aquilo que pode gerar perdas para a organização tais como riscos de falhas em infraestruturas, problemas em aplicações, atrasos e quebras do orçamento de projetos, etc. Para minimizar o possível impacto financeiro, os manuais de gestão risco prescrevem metodologias de mitigação de risco. Mas a sua minimização ou eliminação muitas vezes não é tecnicamente ou financeiramente viável, e como os manuais de sobrevivência ensinam, se não é possível resolver um problema, transfira para o vizinho.

A transferência formal do risco ocorre quando uma parte contrata um terceiro para assumir ou dividir o risco. Um bom exemplo disso ocorre na terceirização de serviços de desenvolvimento de software ou na gestão de infraestrutura. No outsourcing, uma empresa especializada é capaz de lidar mais facilmente com o risco pois possui uma maior escala e conhecimento que a contratante. O caso oposto ocorre quando não existe um relacionamento formal entre as partes. Este é o caso de consultas a especialistas dentro da organização. A apreciação por parte de um terceiro divide o risco técnico do projeto, da solução, e também o minimiza.

Em muitos casos, o risco é mais sutil e está presente na tomada de descisão diária. A compra de um novo equipamento ou software fora de um padrão, por exemplo, pode gerar um problema grave de arquitetura. O alinhamento prévio com o seu par, chefe ou colega divide o risco com a estrutura da empresa. O risco deixa de ser apenas do profissional, da área, do departamento e passa a ser de todos envolvidos no processo de comunicação.

Da mesma forma que faz sentido a transferência do risco para fora, é lógico rejeitá-lo ou criar dificuldades quando vem de fora. Muitas vezes as áreas de negócio aumentam o risco das áreas de tecnologia através de soluções adquiridas do mercado. Certa vez hospedei um servidor com uma solução tipo caixa-preta adquirida durante uma negociação com um cliente pela área comercial. Como não havia manutenção na aplicação, houve vários problemas de disponibilidade após a implementação do sistema. E naturalmente ninguém se lembrava de quem houvera comprado e forçado a implementação “guela abaixo” de TI. O produto foi desativado depois de uma série de tentativas sem sucesso de melhorar a arquitetura da solução e literalmente foi redesenhado. A área de negócio não estava ciente dos riscos operacionais ou não se importava com eles, pois após o fechamento do negócio, “o risco passou a ser da área de TI e não da área comercial”. Na época, lamentei de não ter um meio para vincular a área comercial à solução e desejava algum
instrumento que permitisse operar o produto mas ao mesmo tempo mantivesse o risco da solução com a área de negócio.

Memos de riscos, cartas de compliance ou cartas de riscos são instrumentos que formalizam e declaram para a organização o aumento do risco operacional devido ao descumprimento de um padrão ou norma. Se uma área de produtos desejar implementar uma solução que aumente em demasiado o risco, esta deverá assumir o risco e a área de TI deve emitir um documento contra a área que deve assinar e devolver a TI. Outra forma de não aceitar prontamente o risco é levá-lo em consideração na elaboração do SLA. Quanto maior o risco operacional, piores devem ser os níveis de serviço vendidos por TI.

Na verdade, o Risco Operacional é de toda a empresa. Assim a estratégia de transferir o risco parece ser um contra-senso pois o risco é corporativo e não de uma área, de um profissional. Mas é TI que absorve o primeiro impacto e responde por qualquer problema, da mesma forma que o jurídico responde por um problema legal ou o RH por um passivo trabalhista. Por sua vez, as áreas de negócio muitas vezes desconhecem os riscos tecnológicos ou comportam-se como tal. Transferir formalmente o risco as obriga a uma reavaliação interna do projeto, da idéia. E na eventualidade de um problema, as partes que “sabiam do risco” vão se voluntariar a resolvê-lo pois são sócias do empreendimento e de qualquer problema que venha a ocorrer.

Paulo Farias Castro Filho é engenheiro formado pela UFPE, MSc. em Processos pela UFRJ-COPPE e Especialização em Gestão de Produtos pela FGV. Especialista em gestão de serviços de TI(ITIL, COBIT). Trabalha atualmente na Serasa como gerente da Central de Serviços de TI. Atuou ao longo da sua carreira em diversas áreas tais como desenvolvimento de sistemas, callcenter, canais comerciais, infraestrutura, serviços, gestão de outsourcing, segurança da informação e arquitetura corporativa..

Ver perfil