Operações mais eficazes: Automação em TI

Uma operação de TI é basicamente uma série de rotinas; em média, 80% das atividades desenvolvidas em uma área de TI são repetitivas e, em muitos casos, de baixo valor ao negócio, mas devem ser feitas, pois a não execução delas oferece um risco ao negócio. Essa é a encruzilhada: Se eu fizer tudo certo todo dia, não faço mais que a obrigação, no entanto, se falhar, pronto! Meu erro será lembrado sempre.

Nesse cenário, uma alternativa interessante vem surgindo nos últimos anos para tirar a área de tecnologia dessa roubada e construir uma operação mais inteligente: Automação de Serviço em TI. Mas antes vamos alinhar alguns conceitos.

 

O que é Runbook?

É uma compilação de rotina e procedimentos que o administrador ou operador de TI realiza. Ele pode ser constituído tanto de documentos formais quanto de procedimentos informais estabelecidos na operação, claro que, neste caso, quanto mais informal, maior o risco de falha.
O conceito de Runbook Automation refere-se a quando pegamos essas mesmas rotinas e colocamos em uma ferramenta responsável pela sua execução.
Até aqui nada que impactasse diretamente o Service Desk, no entanto, recentemente, a indústria percebeu que o mesmo conceito adotado à automação dos serviços para a infraestrutura poderia ser aplicado às solicitações de serviços do Service Desk.

 

IT Process Automation

Paradoxalmente, o departamento de TI é o menos automatizado em muitas organizações, acabamos por dispender nosso tempo escasso (e tempo é dinheiro!) em tarefas comuns e repetitivas.
IT Process Automation tem foco em eliminar essas interações manuais de trabalho intensivo, liberando a equipe de TI para executar as tarefas que geram valor ao negócio. Mas cuidado, nem toda tarefa vale a pena ser automatizada, para isto, devemos olhar o ciclo de automação a seguir, que faz parte da metodologia MEFOS (Modelo de Eficácia para Operações de Serviços) de gestão de serviços que, dentro do estágio de formulários complexos, começa a atuar com as automações das requisições de serviços dentro do Help Desk.

 

O que esse Ciclo de Automação quer dizer?

O ciclo acima estabelece cinco passos importantes para a análise e adoção da automação dentro das operações de TI, o conceito é tratarmos uma demanda por vez, gerando um ciclo ao estilo PDCA. Vamos agora nos aprofundar sobre cada uma das etapas.

80/20: O conceito de 80/20 estabelece que 80% das consequências advêm de 20% das causas de um ambiente. Com isso, podemos concluir que 80% do tempo da equipe vai ser consumido por 20% das rotinas existentes e são estas que gerarão um alto retorno de investimento se forem automatizadas. É fundamental começarmos por este grupo de atividades, pois é ele que irá liberar o tempo da equipe para focar nos projetos da TI. Após identificadas as principais demandas, devemos então escolher uma delas e partir para a etapa seguinte.

Matriz Risco e Conhecimento: Agora devemos analisar a atividade que identificamos e validarmos qual é o risco de automatizá-la, em outras palavras, caso não dê certo a atividade automatizada, qual é o impacto para a organização? A resposta a essa pergunta dará a dimensão do risco; com relação ao conhecimento, é óbvio que quanto maior conhecimento for necessário, mais pessoas serão envolvidas no processo de automação, no entanto, como faremos isso somente uma vez, o seu impacto para o projeto é menor. O foco é buscar as atividades de baixo risco e que requerem baixo conhecimento, por isto que, normalmente, as empresas começam com atividades, como: desbloqueio do usuário, reset de senhas de sistemas e rede, entre outros.

Design: Automação é a execução das atividades, mas políticas e padrões serão sempre estabelecidos pelas pessoas da organização. Portanto, a etapa do design é quando planejamos o processo que será automatizado, mapeando a situação atual, estudando os padrões que serão estabelecidos e, por fim, definindo as políticas que serão aplicadas no processo. Um exemplo disso é que, quando automatizamos a criação de usuários na rede, devemos definir a política de nomes e o que será feito, caso já exista o usuário, definir quais atributos deverão ser preenchidos, etc.
Tudo isso é feito na etapa do design. Essa é a mais importante do processo e, por várias vezes, a mais relegada (sei que isso é meio clichê, mas não poderia deixar de frisar).

POC Local: POC quer dizer (Proof of Concept) ou, em bom português, Prova de Conceito; após prepararmos toda a etapa de design, criamos uma operação assistida em que iremos então validar se o processo automatizado está funcionando corretamente. O ponto alto desta etapa é acompanhar a automação, validando sua execução a cada efetivação, assim podemos ter certeza de que os padrões definidos estão sendo seguidos e que não há erros.
Usando o caso acima, após a criação de cada novo usuário pelo processo automatizado, o responsável por essa atividade faria a validação sobre o usuário criado, garantindo que o mesmo fora criado corretamente.
Lembrete: Automatizamos a Execução e não a responsabilidade sobre o serviço.

Operação: Quando finalizamos as etapas e validamos o processo, ele fica pronto para ser entregue à operação e ser utilizado em larga escala pela organização. Vale ressaltar que o que automatizamos é a execução das atividades e não a responsabilidade sobre elas. Portanto, as pessoas que eram responsáveis pela gestão dos serviços continuam sendo, só que agora podem dispender menos tempo na execução e somente controlar as atividades. Mas caso seja necessário revisar a etapa de design com alteração nas politicas e padrões, cabe ao gestor do serviço este papel.

 

Automatizar deixa de ser uma opção para se tornar uma saída clara, afim de deixarmos nossas operações mais inteligentes. Ninguém gosta de esperar e quanto mais ágil formos aos olhos do usuário, mais aumentaremos seu grau de satisfação, reduzindo custos da operação.