6 razões pelas quais os projetos de Automação de Processos Robóticos (RPA) falham e como evitá-los

Foto de chuttersnap em Unsplash

A Automação de Processo Robótico (RPA) é um tópico importante nos campos de automação e IA. Essencialmente, o RPA é uma ferramenta de software que obtém automação imitando ações humanas baseadas em regras e repetitivas. O RPA usa um robô ou bot para automatizar processos. Hoje, existem muitos fornecedores de RPA no setor, com os principais players sendo Automation Anywhere (AA), Blue Prism e UiPath. Se você é uma pequena empresa ou estudante que explora o campo RPA, a maioria dos fornecedores também fornece uma versão comunitária de suas ferramentas, que é gratuita.

A implementação de RPA segue o ciclo de vida de desenvolvimento do sistema (SDLC). Este artigo detalha as possíveis falhas em um projeto RPA que podem ocorrer nos estágios do SDLC e como evitá-las.

Fases do SDLC do projeto RPA
1. Planejamento: escolhendo o processo certo para automatizar 2. Análise: a batalha de requisitos 3. Design: como evitar a criação de um projeto de solução ruim 4. Desenvolvimento: Reconhecendo as diferenças de ambiente pela frente 5. Testando: cenários de teste frequentemente perdidos no RPA projetos 6. Hiper-cuidado: e se o robô falhar com muita frequência?

1. Planejamento: escolhendo o processo certo para automatizar

A primeira etapa de um projeto RPA é escolher o processo certo para automatizar. A pessoa que faz a seleção e a avaliação deve estar familiarizada com os candidatos ao processo e com a ferramenta RPA. Existem duas abordagens para avaliar se um processo é viável para RPA, que são os métodos de cima para baixo e de baixo para cima.

Método de cima para baixo: escolhendo um processo identificando os benefícios relacionados aos negócios
Método de baixo para cima: escolhendo um processo avaliando a viabilidade técnica

O método descendente é normalmente realizado por uma pessoa gerencial que conhece e conhece o contexto do processo, como o número de funcionários envolvidos no processo, o atual contrato de nível de serviço e o impacto da RPA na outra. processos e unidades de negócios. Esse método geralmente é feito em um nível muito alto, onde as pessoas estão olhando para várias oportunidades de processo ao mesmo tempo.

Por outro lado, a abordagem de baixo para cima é feita pelo arquiteto ou desenvolvedor da solução RPA, que entende a metodologia e as funções de desenvolvimento da RPA. A abordagem de baixo para cima inclui a identificação da disponibilidade do ambiente, segurança e disponibilidade do robô. Essa abordagem também pode ocorrer apenas na fase de análise quando o desenvolvedor está reunindo requisitos.

O acesso a um processo com ambas as abordagens garante a viabilidade do RPA e evita o desperdício de recursos nas próximas atividades.

2. Análise: a batalha de requisitos

Quando um processo é selecionado para o RPA, podemos começar a reunir requisitos. Se o RPA for o primeiro projeto de automação da organização, é provável que a maioria das partes interessadas / usuários não esteja familiarizada com a tecnologia. Assim, o analista de negócios da RPA deve apresentar a RPA às partes interessadas relevantes. Seria mais fácil para o analista de negócios reunir requisitos dos usuários quando eles souberem como o RPA funciona e seus benefícios. Freqüentemente, o analista de negócios pode achar que os usuários perdem certas etapas e resultados necessários nas discussões de requisitos, pois podem não estar familiarizados com a automação e até que ponto o robô RPA pode ou não fazer.

Foto de James Pond no Unsplash

O outro cenário que um analista de negócios pode enfrentar são solicitações de requisitos adicionais dos usuários. A regra geral, se requisitos adicionais devem ser adicionados ao escopo, é primeiro entender quanto tempo está sendo gasto pelo usuário no escopo adicional no dia a dia; e o número de usuários que usam as funções do novo escopo. O analista de negócios também pode precisar gastar uma boa quantidade de tempo para analisar os requisitos adicionais. Um escopo adicional pode adicionar facilmente o esforço / tempo necessário para o desenvolvimento e o teste.

Portanto, é aconselhável se comunicar com os usuários sobre o escopo e como o escopo adicional pode prejudicar o cronograma de desenvolvimento.

3. Design: como evitar criar um design de solução ruim

Depois de entender os requisitos, é hora de criar um plano para o nosso robô! Os robôs RPA são tecnologias de automação projetadas para reduzir tarefas de trabalho redundantes para seres humanos e, portanto, excelentes para realizar trabalhos repetitivos e de baixo valor.

A maioria dos robôs RPA possui quatro etapas típicas ao automatizar um processo, incluindo extrair e validar entradas de dados, automatizar o processo principal (por exemplo, entrada de dados, cálculos) e gerar saídas e resultados de dados.

Você pode ler mais sobre as quatro etapas essenciais aqui. Como os robôs estão realizando trabalhos repetitivos, muitos ciclos e lógica if / else estão acontecendo nos bastidores. Na fase de design, é importante corrigir a lógica de codificação para evitar problemas de design no futuro. Os exemplos a seguir são algumas das considerações que o arquiteto da solução deve tomar nota ao criar o design da solução em um projeto RPA:

Dicas de design da solução RPA: 1. A lógica principal do loop para processar todos os registros (entrada de dados) deve estar em vigor para todos os processos
2. O robô deve gerar resultados para cada registro (entrada de dados), como "OK", "falhou" e, se necessário, comenta 
3. O robô deve notificar o usuário quando concluir um processo através da janela pop-up, email, etc.
4. Planejamento de reversão: se ocorrer um erro, volte para a etapa X para continuar processando o próximo registro
5. Planejamento de reversão: se ocorrer uma falha do sistema, pare o processo e feche o aplicativo antes que o robô saia
6. Verifique se todos os aplicativos usados ​​estão fechados antes da saída do robô

Passar tempo suficiente na fase de projeto é crucial para garantir um ciclo de vida de desenvolvimento de RPA suave. O documento de design da solução também deve listar todas as possíveis exceções que aconteceriam e explica como os robôs devem lidar com as exceções.

4. Desenvolvimento: Reconhecendo as diferenças ambientais

Os robôs RPA confiam na interface do usuário para saber como e quando deve inserir uma tecla de atalho, clicar ou executar uma função. Telas de aplicativos idênticos em todos os ambientes (desenvolvimento, teste de aceitação do usuário (UAT) e ambientes de produção especificamente) ajudariam a tornar o processo de desenvolvimento mais gerenciável. No entanto, os comportamentos de aplicativos geralmente são ligeiramente diferentes em cada ambiente e quando usados ​​por diferentes tipos de usuários. Assim, o desenvolvedor deve planejar com planos de 'contingência' quando essa discrepância for identificada.

Foto de Kevin Ku no Unsplash

No melhor cenário, o arquiteto da solução deve ter identificado e abordado os problemas na fase de design. Assim, é possível que discrepâncias sejam encontradas apenas no desenvolvimento. Quando tal situação ocorre, o desenvolvedor deve discutir com o arquiteto da solução para verificar se um novo design de solução é necessário e fazer uma análise de impacto nas outras etapas do processo.

Outra regra prática ao desenvolver o RPA é escrever códigos modularizados e reutilizar os módulos sempre que necessário. Os desenvolvedores de RPA podem enfrentar situações em que o fluxo do processo precisa ser alterado devido a requisitos adicionais ou negligenciados. Assim, um código modularizado economizaria tempo, pois o desenvolvedor só precisa fazer alterações em determinadas linhas de código para refletir as alterações necessárias.

5. Teste: cenários de teste que geralmente são perdidos em projetos de RPA

Existem duas áreas principais a serem testadas nos robôs RPA: relacionados ao RPA e aos requisitos de negócios. Ao fazer o teste, é fácil perder as especificações funcionais relacionadas à tecnologia RPA, pois elas podem não estar explicitamente listadas nos documentos de design. Aqui estão alguns cenários de teste para as duas áreas:

Cenários relacionados à RPA - Cenários de janela, objeto não encontrado - Vários robôs executando o mesmo processo ao mesmo tempo - Todos os aplicativos fechados antes da saída do robô - Arquivo de log é salvo e legível para cada execução do processo
Cenários relacionados aos negócios - Cenário de entrada de dados não fornecido - Insira com êxito o nome, a idade e salve o perfil do cliente - O resultado do cálculo está correto - Imprima o resultado do erro se o nome não tiver sido fornecido e continue o processo - Número de FTE salvos (macro KPI)

Os cenários de teste se aplicam a todos os ambientes e devem incluir o teste do maior número possível de cenários negativos. Na fase UAT, os usuários poderão ver a saída 'física' do robô e, frequentemente, podem solicitar alterações cosméticas em termos de como a saída é apresentada. Portanto, os desenvolvedores sempre devem verificar com os usuários se eles estão satisfeitos com os resultados dos testes.

6. Hiper-cuidado: E se o robô falhar com muita frequência?

Parabéns! Seu robô RPA já foi implantado! Agora é apenas a questão de monitorar os robôs para garantir que eles estejam executando o processo conforme acionado.

Podemos definir um cenário como 'Robô RPA com defeito' se a execução do processo não atingir a meta esperada de resultado / KPI (indicador de desempenho chave), geralmente especificada no termo de abertura do projeto.

Alguns exemplos de KPI RPA incluem: 
- Número de FTE salvos (KPI de macro) -% de tempo / execução que precisa de intervenção humana - Número de registros a serem processados ​​por hora / dia - Número de registros processados ​​com sucesso pelo robô

Além de monitorar o comportamento dos robôs e investigar as exceções, as pessoas geralmente perdem o registro e a medição da eficácia dos robôs. Portanto, a equipe da RPA deve preparar uma lista de KPIs para medir e recursos dedicados a entender e analisar se a implementação da RPA é bem-sucedida.

Em uma nota lateral, são necessários aprimoramentos se os robôs não estiverem funcionando conforme o esperado ou lançando muitas exceções de volta ao usuário. É típico implantar um processo por 2 a 3 vezes no ambiente de produção, se for o seu primeiro projeto de RPA.

Foto de Phillip Glickman no Unsplash

Feliz automação!