Gestão do RPA e Automação de Processos – desafios e lições aprendidas

Alguns dos benefícios do RPA estão relacionados com a libertação de pessoas para tarefas de maior valor acrescentado e estratégicas, maior flexibilidade na resposta a picos de volume, eliminação do erro humano e melhoria da experiência de clientes e colaboradores. Não menos importante, o RPA tem impulsionado programas de reskilling em funções de Developer, Business Analyst ou Bot Controller com taxas de sucesso notáveis.

O mercado de RPA tem crescido de forma acelerada e prevê-se que atinja os $20.1 biliões até 2030. Este rápido crescimento aliado a algum desconhecimento das necessidades da tecnologia e reduzido acompanhamento por parte dos fornecedores, tem gerado vários desafios na gestão e escalabilidade dos programas de automação. As empresas tipicamente selecionam um fornecedor e um parceiro e realizam uma prova de conceito com sucesso, no entanto os verdadeiros desafios surgem depois. Dificuldades na integração do RPA com outras tecnologias, falta de suporte e documentação, desenvolvimentos pouco robustos e escaláveis, dificuldades na definição e acompanhamento de KPIs fiáveis, problemas de Infraestrutura e inexistência de capacidades de self-recovery e orquestração avançada, poderão explicar porque a grande maioria das organizações tem menos de dez robots em produção e apenas 40% das licenças RPA são efetivamente usadas.

Para responder a alguns dos desafios que elenquei acima, uma das recomendações unânimes no mercado é a criação de um centro de excelência (CoE). Apesar do RPA ser Business Driven e não IT Driven, esta equipa tem de possuir um elevado conhecimento tecnológico que lhe permita integrar diferentes tecnologias e definir e monitorizar boas práticas. Para além disso, esta equipa fornece serviços de automação de elevada qualidade alinhados com os objetivos estratégicos da organização e assegura a comunicação, recursos e standards de segurança necessários.

Tipicamente um processo RPA tem quatro fases após a oportunidade ter sido identificada e priorizada (idealmente de forma automática): Desenho, Desenvolvimento, Go-Live e Monitorização/Manutenção. Os projetos de RPA não terminam com a entrada em produção da solução. Aliás é a partir desta fase que o verdadeiro desafio inicia e frequentemente o esforço de monitorização e manutenção está diretamente relacionado com a qualidade do Desenho e do Desenvolvimento. Além disso, existe toda uma componente de melhoria contínua ao nível da orquestração, Change Management e Reporting que é essencial para o crescimento sustentado de um programa de RPA e futura transição para Intelligent Automation, passando a ser agnóstico à tecnologia e orientado ao processo.

Partilho de seguida algumas boas práticas e lições aprendidas nos últimos sete anos a trabalhar em Automação de processos com RPA e outras tecnologias:
‍

1. Desenho:

a. Cerca de 80% de uma solução de RPA eficiente e escalável começa com o mapeamento do modelo ASIS (processo manual sem automação) e modelo TOBE. Umas das grandes dificuldades das organizações que utilizam RPA é a análise funcional, na qual tipicamente se perdem oportunidades de melhoria e simplificação do processo antes da sua automação. Quando nesta fase o processo ASIS não é desafiado, as equipas de automação não descobrem a causa raiz dos seus problemas, acabando por resolver sintomas em vez dos verdadeiros problemas e como consequência automatiza-se um processo mal desenhado e com bastantes problemas que não serão resolvidos com a sua Automação.

b. Um erro bastante comum nas equipas de automação é quando o modelo ASIS e TOBE é linear e praticamente o mesmo, ou em alguns casos nem sequer existe modelo TOBE no PDD (Process Definition Document). Frequentemente o fluxo do processo não tem variações nem exceções e apenas tem o “Happy path”. Apenas cerca de 30-40% das transações de um processo seguem o “Happy Path”, pelo que esta situação normalmente indica que a análise funcional está incompleta e como consequência será desenvolvida uma solução que não estará minimamente preparada para lidar com as variações e exceções que existem em todos os processos de negócio, o que naturalmente irá impactar a taxa de sucesso.

c. O modelo TOBE deve espelhar a solução e raramente é uma réplica do modelo ASIS, visto que deve incorporar alterações e melhorias ao processo que irão permitir aumentar a sua taxa de sucesso e reduzir os tempos de execução, como por exemplo a integração com BPM, APIs, BDs, etc. É importante ter em conta que na grande maioria dos casos os automatismos não terão 100% de sucesso (nem se justifica o esforço) e que é necessário assegurar de forma clara quem será o responsável pelo tratamento de exceções.

d. O documento funcional (PDD) deve descrever de forma clara o plano de contingência face a situações de catástrofe (ex: servidores aplicacionais em baixo) ou indisponibilidade de alguma das aplicações usadas pelo RPA.
‍

2. Desenvolvimento:

a. Devem ser sempre utilizadas filas de trabalho (Work Queues) que permitem que o processo seja executado em mais do que uma máquina em simultâneo.

b. Distinção entre Dispatcher (processo que alimenta uma fila de trabalho) e Executor/Worker (processo que executa transações a partir de uma fila de trabalho). Esta distinção pode ser assegurada através de argumentos no processo RPA, não sendo necessário criar dois processos distintos.

c. São raras as situações que justificam que um processo RPA termine de forma abrupta, mesmo quando se depara com situações não previstas. Devem ser incluídos mecanismos robustos de criação de logs e de gestão de exceções para lidar com variações e exceções ao processo, repondo o estado inicial das aplicações se necessário.

d. Os tipos de exceção devem ser distinguidos entre System Exception (erros de RPA e aplicacionais) e Business Exception (regras de negócio, situações fora de âmbito, etc.). Tipicamente um processo RPA não deve ter mais de 10% de exceções de sistema.

e. Todos os desenvolvimentos devem ter como base um template único e standard, garantindo desta forma que todos os developers seguem as boas práticas definidas e programam da mesma forma, facilitando a manutenção.

f. O desenvolvimento deve ser modular com vista a reutilizar blocos em outros processos que utilizem as mesmas aplicações, acelerando o tempo de desenvolvimento e reduzindo o esforço de manutenção.

g. O desenvolvimento deve privilegiar sempre que possível a utilização de APIs ou BDs em detrimento de ações no front-end das aplicações que são naturalmente mais propícias a alterações e a erros.
‍

3. Go-Live

a. Após conclusão do desenvolvimento, devem ser realizados testes exaustivos com a equipa de negócio, não apenas com casos de sucesso, mas também forçando erros ao longo do processo para garantir que o automatismo se comporta conforme esperado.

b. A entrada em produção do processo deve ser aprovada pelo negócio e por um QA que assegure a revisão da solução e a sua publicação em produção, passando o processo RPA a ser executado de forma automática no horário e frequência acordados e responsabilidade da equipa de manutenção.
‍

4. Monitorização/Manutenção

a. Segregar desenvolvimento de manutenção. Tipicamente na equipa de manutenção encontram-se os Developers mais experientes e com maior conhecimento dos procedimentos em vigor.

b. A equipa de manutenção deve assegurar toda a componente de melhoria contínua das operações do RPA, nomeadamente o acompanhamento das execuções dos processos, a redução de tempos de execução, correção das exceções com maior volume e incorporação de evolutivos que aumentem o âmbito dos automatismos e as suas taxas de sucesso.

c. O Reporting deve ser baseado no volume real de casos tratados pelos automatismos e de preferência através de um dashboard em BI assente em dados estruturados que são gerados pelos processos RPA.

d. Devem ser implementados mecanismos de orquestração avançada, que permitam maximizar a taxa de ocupação das máquinas e o cumprimento dos horários definidos, como por exemplo agendamentos dinâmicos com base no volume de casos pendentes, SLAs e máquinas livres.

e. Os processos RPA devem possuir mecanismos automáticos de reprocessamento de System Exceptions e de paragem automática caso alguma das suas aplicações esteja indisponível.

f. Devem ser configurados alarmes que permitam que o suporte seja proativo e evite Downtime.

Não existe uma fórmula mágica para a adoção do RPA numa organização, pois mesmo empresas do mesmo setor têm as suas especificidades e é sempre necessário adaptar a tecnologia às necessidades da organização e não o contrário. O RPA quando usado de forma isolada tem bastantes limitações, pelo que tem sido complementado com tecnologias de BPM, IDP, NLP, Process Mining, Chatbot e Machine Learning, tornando-se uma tecnologia bem mais poderosa na simplificação, melhoria e automação de processos de negócio.

Atualmente as organizações operam num cenário empresarial altamente desafiante e imprevisível, com fenómenos como a Great Resignation, Quiet Quitting e a falta de talento qualificado em automação de processos. Em 2023 espera-se que as organizações priorizem estratégias de melhoria da experiência dos colaboradores e a automação de processos cada vez mais complexos e com impacto em clientes recorrendo ao RPA e outras tecnologias complementares. “Processos e sistemas ineficientes estão a provocar frustração e o esgotamento dos colaboradores", escreveu recentemente a Qualtrics. O foco da automação deixará de ser apenas horas poupadas/evitadas e passará a contemplar a melhoria da experiência dos seus colaboradores de forma global com o objetivo de proporcionar melhores condições às suas pessoas e melhorar as taxas de retenção de talento.

Nota: As opiniões expressas acima são apenas minhas e não representam a minha entidade patronal.

Este artigo integra-se no ciclo anual de reflexão sobre tecnologia, negócio e sustentabilidade do Nova SBE Digital Experience Lab. Para receber mais notícias sobre os eventos e artigos que o Digital Experience Lab está a organizar, subscreva a nossa newsletter mensal.