RPA é lindo e funciona! Mas e quando dá erro?

Começou a desenvolver RPA?

O processo de desenvolvimento de RPA – ou automação de processos robóticos – muitas vezes começa pelo mapeamento do processo. Normalmente, se mapeia o processo como deveria ser executado, ou seja, o caminho feliz. Mas e quando o caminho feliz não ocorre?

RPA como funciona?

Começou a desenvolver RPA?

O processo de desenvolvimento de RPA – ou automação de processos robóticos – muitas vezes começa pelo mapeamento do processo. Normalmente, se mapeia o processo como deveria ser executado, ou seja, o caminho feliz. Mas e quando o caminho feliz não ocorre?

Nesse artigo, vamos abordar dois tipos de problemas que podem acontecer com você e compartilhar 5 experiências vividas pelo nosso time!

Após fazer o script do robô, e finalmente testá-lo, pode acontecer uma falha no meio do processo, e ele deixar de funcionar. Porém, podem existir diversas causas para o mau funcionamento, que podem ser classificadas entre problemas no processo e problemas no robô. Os problemas no processo acontecem quando ocorrem situações fora dos cenários conhecidos, ou seja, o mapeamento do processo não contempla todos os cenários necessários. Enquanto os problemas no robô são inerentes ao próprio script de automação, assim, são falhas causadas pelo próprio desenvolvedor do RPA.

Quando não se sabe para onde ir, qualquer caminho basta

Antes de se automatizar um processo, é preciso saber o que desejamos alcançar. Ao definir qual o objetivo do RPA, pode-se traçar o passo-a-passo de como atingir este resultado.

Mas não apenas o que se espera fazer deve ser definido, mas também, como fazer. Apesar do desenvolvimento de RPA possuir complexidade menor do que o desenvolvimento dos sistemas em si, ainda podem ocorrer erros semânticos e de sintaxe da tecnologia utilizada para construir o robô.

Assim, “desenhar” como se pretende implementar a automação do processo, antes de realmente fazê-lo, mitiga as chances de ocorrerem erros inerentes ao próprio robô.

Quando iniciei o meu primeiro projeto, o que deveria ser feito parecia óbvio para mim. E o que não soubesse, iria descobrindo ao longo do tempo. Mas ao utilizar esta abordagem, no final do processo, percebi diversas coisas que poderiam ter sido feitas de uma forma melhor. 

É claro  que após ganhar alguma experiência, temos mais conhecimento do que tínhamos no início. Mas com um planejamento mais estruturado, é possível diminuir o nível de retrabalho.

Parecia algo simples, até precisar ser feito

Fazer um clique do mouse em um botão. Esta é uma das coisas mais básicas que podemos fazer na automação de um processo, mas que pode trazer algumas dificuldades.

Como no caso da automação de programas no desktop, onde nem sempre é possível ter acesso aos identificadores dos elementos nas janelas dos programas, é preciso encontrar soluções alternativas. Uma delas, pode ser o uso de imagens para encontrar os elementos na tela. Essa pode ser uma boa solução para quando nada mais funciona.

Porém, é recomendável evitar o uso de detecção de imagens se possível, pois este método pode ser muito sensível à mudanças, visto que qualquer alteração na aparência da interface gráfica, pode “quebrar” o robô, que não irá mais reconhecer o elemento. Além disso, dependendo da interface, o robô pode executar ações indesejadas ao interagir com os elementos errados, caso haja muitos componentes parecidos.

Assim, mesmo ações simples que se deseja automatizar, podem se tornar complexas, devido à limitações da tecnologia ou do processo em si.

Prepare o caminho não-feliz

Durante o mapeamento do processo, é planejado o cenário ideal da execução do RPA, mas podem ocorrer situações que podem causar diversos problemas, como um programa deixar de responder, dados incorretos serem fornecidos ao robô, entre outros.

Então, o que deve ser feito nesses casos? Assim como é planejado o comportamento do robô no caminho “feliz”, também é importante definir como proceder quando erros inerentes ao processo em si ocorrerem. 

Para saber o que fazer quando o cenário ideal der errado, é preciso saber o que pode dar errado. Desta forma, é indicado conhecer bem o processo que será automatizado, além de testar o robô nas situações conhecidas que podem causar erros. Por exemplo, se o RPA depende de dados externos para funcionar, então testar com várias entradas de dados diferentes pode mostrar erros antes desconhecidos.

E como não é possível conhecer todas as exceções que podem acontecer, definir uma ação caso o robô não encontre uma resposta prevista a cada etapa, já é uma forma de lidar com comportamentos inesperados que podem ser apresentados pelo sistema a ser automatizado.

Os logs são seus amigos

É bem provável que a tecnologia que esteja usando para desenvolver o RPA produza um arquivo de log. Ele pode ser usado para fornecer informações sobre a execução do seu robô. Dependendo do quão detalhado ele for, você pode saber quais passos foram executados com sucesso, e o quê exatamente deu errado.

Com as informações obtidas do arquivo de log, é possível reproduzir o erro e definir em quais condições ele acontece. Ao saber qual problema aconteceu em uma determinada etapa da execução do robô, já foi dado um passo na investigação de como resolvê-lo. 

Peça ajuda

Após passar um longo período de tempo tentando resolver um mesmo problema, a sua visão do mesmo acaba ficando “cansada”, e a solução que você poderia encontrar em outras condições, pode passar despercebida.

Assim, um olhar externo pode fazer toda a diferença. Ao pedir ajuda para outros colaboradores, que possuem suas próprias experiências, é possível obter uma nova percepção dos obstáculos enfrentados.

Desta forma, a cooperação pode te ajudar a resolver problemas mais facilmente do que seria ao trabalhar sozinho.

Esse é o nosso primeiro artigo aqui no Blog da Deltapoint. Então, aproveito para convidar você para acompanhar nosso Instagram @deltapointbr    

Até a próxima!

Samantha Gomes
Sou estudante de Tecnologia em Análise e Desenvolvimento de Sistemas no IFG e Desenvolvedora RPA na Deltapoint. Meus interesses são automação e desenvolvimento de software, além de compartilhar conhecimento!

O que é SRE?

Site Reliability Engineering (SRE) é o resultado da combinação de responsabilidades de operações de TI com desenvolvimento de software. Com o SRE, há uma expectativa inerente de responsabilidade para atender aos objetivos de nível de serviço (SLOs) definidos para o serviço que eles gerenciam e os acordos de nível de serviço (SLAs) que prometemos em nossos contratos.

Construindo sistemas distribuídos confiáveis

O que significa observabilidade, como definir objetivos de nível de serviço (SLOs), como a observabilidade ajuda a tornar os sistemas mais confiáveis ​​e como validar sua prática de observabilidade.

Imagem de um notebook aberto com duas pessoas se comunicando.

Como a observabilidade ajuda na confiabilidade

O que significa observabilidade, como definir objetivos de nível de serviço (SLOs), como a observabilidade ajuda a tornar os sistemas mais confiáveis ​​e como validar sua prática de observabilidade.

Preparamos sua empresa ou startup para decolar

Construímos o Sizify – A única plataforma que integra software e serviços que garante planejamento , produtividade , controle, qualidade e segurança.

    SOFTWARE DEV

    Nossos squads multidisciplinares também entregam tudo pronto ! Desde desde a concepção, design, arquitetura até a execução dentro do prazo e budget.

    QA/X

    O Sizify® por observabilidade e monitoramento ativos, reduz o GAP entre:

    a) experiência do usuário durante o uso;

    b) gestão de confiabilidade de software e ambientes;

    c) exigências de qualidade do produto.

    MEASURMENT

    A analise de ponto de função do Sizify®  garante mais que uma simples medida. É um modelo de governança com apoio de indicadores, frameworks e estimativas de custos e prazos. Identifica  áreas de risco do projeto evitando  rupturas de escopo, prazo e budget.