RPA (Robotic Process Automation) é uma tecnologia que tem sido bastante utilizada para a automação de tarefas repetitivas nas organizações. Já falamos em um artigo anterior dos cuidados a serem tomados durante a realização de projetos em RPA.
No entanto, especialmente em empresas que estão começando o uso de RPA, costumam surgir dúvidas sobre em quais cenários a utilização de RPA não seria a melhor solução. Neste artigo vamos focar em alguns cenários mais frequentes, onde não é recomendada a utilização desta tecnologia. Vamos lá?
1) Tarefas que exigem julgamento, intuição e análise humana
São casos em que para realizar uma determinada tarefa, existe a necessidade de uma análise ou decisão por uma pessoa, baseada em critérios subjetivos e intuitivos. Imagine, por exemplo, um gestor de uma equipe de atendimento de chamados, que optou por usar apenas o “feeling” para distribuir os chamados: de acordo com a gravidade, o tipo de problema, a prioridade e até mesmo o cliente em questão, o gestor direciona para o membro da equipe que considera que melhor vai tratar este chamado. Esta parametrização não está em nenhuma tabela ou sistema, de fato existe apenas na cabeça do gestor. Quando você não consegue “traduzir” a lógica do processo de análise ou decisão de uma pessoa para regras pré-definidas, então você saberá que está lidando com subjetividade. Este tipo de análise subjetiva/intuitiva não é possível nas ferramentas de RPA, embora existam iniciativas paralelas de Inteligência Artificial e Machine Learning que prometem avanços significativos neste campo, quando integradas a ferramentas de RPA.
2) Envio de dados entre sistemas que possuam nativamente interfaces de integração
Se existe a necessidade de enviar dados do sistema A para o B, e estes sistemas podem se conversar de maneira sistêmica (ex: através da chamada de webservices ou APIs), é mais recomendado utilizar os recursos nativos de integração, do que configurar um processo no RPA para fazer o envio manual dos dados de um sistema para outro. Dito isto, as ferramentas de RPA dispõem de recursos de integração sistêmica que podem ser utilizados, como por exemplo conexão direta a banco de dados e chamada à APIs. Normalmente, no entanto, estes recursos de integração são utilizados no contexto de um processo maior, em que outras tarefas manuais foram automatizadas, e adicionalmente foi necessário realizar alguma integração sistêmica. Mas cabe aqui ressaltar que não existe nada de errado em promover, via RPA, a integração de dados entre sistemas que dispõem de APIs. Por exemplo, pode acontecer que o custo para configurar as integrações entre os 2 sistemas seja muito alto, ou o prazo necessário para esta implementação não atenda a necessidade do negócio, nesse caso a automação via RPA pode ser sim uma excelente alternativa.
3) Mudanças previstas (ou constantes) em sistemas usados na automação
Caso exista a visibilidade, a curto ou médio prazo, da migração para uma nova versão de uma aplicação que seria utilizada na automação de um processo, o recomendado é aguardar a finalização desta migração, para então se pensar na robotização. Já que, geralmente, não se sabe os impactos que a nova versão irá gerar nas telas ou comportamento da aplicação. Da mesma forma, se uma determinada aplicação sofre mudanças constantes pelo fabricante, estas mudanças podem eventualmente impactar na execução do processo no RPA. A automação em ambos os casos ainda pode ser feita, mas haverá a necessidade de constantes atualizações na ferramenta de RPA para se adequar as mudanças, o que vai diminuir ou inviabilizar os ganhos obtidos com a automação ou criar expectativas diferentes das experiências vividas.
4) Processos instáveis (ou novos)
Se uma determinada tarefa ou processo tem diferentes formas de ser executadas, seja por uma variabilidade natural do processo, ou pela falta de padronização na organização (cada colaborador executa o processo da forma que acha adequado), não é recomendado prosseguir com a automação. Da mesma forma, caso um determinado processo seja novo na organização, antes de se pensar numa automação é recomendado que este processo seja formalmente definido e executado, até que se tenha certeza de que é de fato o processo mais adequado.
5) Processos com alta quantidade de exceções ou caminhos alternativos
Caso uma tarefa ou processo possua uma alta quantidade de exceções/erros ou caminhos alternativos, que mudam a forma e os passos a serem executados, teoricamente ainda seria possível realizar a automação. Mas o custo para esta implementação será muito alto, já que é preciso configurar dentro do processo no RPA todas as exceções, erros e fluxos alternativos existentes. Assim, na maioria dos casos o retorno obtido da automação não será interessante em comparação com os custos de desenvolvimento e manutenção do processo no RPA.
Percebam que, exceto no caso do primeiro item, para os demais casos nada impediria a automação na prática. Porém, é importante que fique claro a todos os envolvidos as particularidades que certamente ocorrerão nestes casos, como a necessidade constante de realizar manutenções no processo na ferramenta de RPA. É recomendado, assim, realizar um bom estudo de ROI para verificar se os custos com a implementação e manutenções constantes na ferramenta de RPA serão compensados com os retornos obtidos com esta automação.
Fique ligado, este artigo terá uma segunda parte com outros cenários! Até lá!
