Quando executamos projetos de implementação em ferramentas de RPA, a primeira ação que é realizada é levantar como o processo é executado hoje de forma manual.

Este levantamento normalmente é feito através de workshop(s) com o cliente, em que alguém da equipe com profundo conhecimento do processo, demonstra exatamente como é feita a execução, acessando as telas nos sistemas, realizando as ações e explicando as regras de negócio.

Via de regra, no entanto, o que costuma ser apresentado é o famoso “caminho feliz” (happy path) do processo, em que tudo ocorre como planejado e o processo é concluído com sucesso. Também costumam ser demonstrados os fluxos alternativos mais comuns (ex: caso a solicitação seja de um determinado tipo, algumas telas ou ações apresentam comportamento diferente).

Mas um aspecto que percebemos que não costuma aparecer nestes workshops, e nos quais nós, como implementadores de projetos em RPA, com frequência precisamos “instigar” o cliente a falar mais, são as exceções e erros que podem ocorrer durante a execução do processo.

Vejamos alguns exemplos:

• O sistema apresenta uma tela ou mensagem com um erro técnico, que normalmente ocorre por um problema na massa de dados sendo utilizada ou um bug ou indisponibilidade do sistema. Estes são erros mais difíceis de se detectar de antemão, porque necessitam de uma certa conjunção de fatores para que ocorram;

• O usuário do sistema demonstrou a aprovação de uma solicitação, mas pode esquecer de comentar de possíveis validações que o sistema realiza que podem gerar mensagens de alerta/erro em tela, impossibilitando a conclusão da ação. Por exemplo, num processo de renovação cadastral, o usuário do sistema pode esquecer de demonstrar um erro que pode ocorrer caso o cliente tenha pendências financeiras com a organização. Este erro pode inviabilizar a continuidade do processo, ou direcionar para um fluxo diferente de telas. Este é o tipo de situação mais fácil de se prever de antemão, mas nem por isso escapa de passar batido durante as demonstrações dos usuários do sistema.

• O usuário do sistema esqueceu de comentar de mensagens informativas diversas que podem ser exibidas pelo sistema, de acordo com algum critério ou regra de negócio.

Mas, afinal, por que é importante levantarmos estas situações?

Isto ocorre porque na programação do robô, ele é preparado para tratar apenas das telas e respostas do sistema que foram efetivamente mapeadas/identificadas.

Imagine, por exemplo, que foi automatizado uma tela com um botão de “Concluir”, em que ao clicar leva para uma tela com a mensagem “Operação realizada com sucesso”. Caso o levantamento do processo identifique apenas esta resposta possível para a ação, de fato será apenas esta tela e esta mensagem que o robô estará preparado para identificar. Caso outra mensagem apareça, ou seja exibido um alerta de uma forma diferente (ex: uma janela popup, em vez de exibir a mensagem em tela), o robô não reconhecerá aquela tela ou mensagem e não saberá o que fazer, levando a uma interrupção da execução do processo.

Assim, nossa recomendação é que, durante o levantamento e apresentação do processo, as seguintes informações procurem ser identificadas em conjunto com o cliente:

• Mensagens de alerta/confirmação (ex: sistema questionando se deve ou não dar andamento numa ação);

• Mensagens informativas: estas ocorrem com frequência e servem apenas para mostrar uma informação para o usuário, ao clicar em OK o processo dá andamento normalmente. Ocorre que em muitos casos são mensagens “popup” que quando não são mapeadas, podem ocasionar a interrupção do processo, da mesma forma que mensagens de alerta e erro;

• Mensagens de validações do sistema: mensagens que, por exemplo, informam que um campo obrigatório está vazio ou foi preenchido incorretamente, que podem aparecer como mensagens popup ou mensagens diretamente em tela;

Mensagem de validação como popup:

Mensagem de validação em tela:

• Telas alternativas que podem ser exibidas dependendo de uma regra de negócio ou situação;

• Mensagens de sucesso ou erro/falha na realização de uma operação. Especial atenção as mensagens de erro, em que deve ser questionado o que o robô deve fazer se a operação não foi realizada com sucesso.

Mensagem de sucesso:

Mensagem de falha:

• Caso seja possível, levante também possíveis erros técnicos que podem ocorrer durante a execução do processo:

Num próximo artigo, falaremos das tratativas mais comuns de serem configuradas numa automação com RPA. De forma que se algo não previsto ocorrer durante a execução do processo, o processo não seja interrompido bruscamente, ao mesmo tempo que sejam dados os devidos direcionamentos para verificação e correção dos problemas. Fique ligado!