RPA como usar e dicas de prevenção Confira aqui! Qintess

Robotização de processos automatizados (RPA). O lado negativo dessa automatização e alguns cuidados e prevenções que podemos ter. Confira aqui!

Sou fã das tecnologias de robotização de processos automatizados (RPA), mas fico bastante surpreso que, com um avanço dessa magnitude, no final, acabo tendo a sensação de entrar em uma máquina do tempo que me leva de volta há 30 anos.

Já vi muitas implementações de RPA e o resultado é fantástico, mas quando olho para o que está por trás de tantas robotizações, volto ao passado. Voltamos ao ponto em que não tínhamos boas práticas de fabricação de software, apenas nos concentramos em fazer um programa funcionar da melhor forma, não importa como o fizéssemos e com poucas regras a seguir.

Hoje em dia, quando fazemos um software, nos preocupamos com o nome, que é uma regra básica, verificamos se as variáveis ​​estão sendo usadas corretamente, usamos paramétricas, não usamos valores no "hard", nos preocupamos com os aspectos de segurança, revisamos as instruções do que estamos usando, temos arquitetos que definem padrões, temos software que inspeciona o que estamos fazendo para garantir as boas práticas e muito mais.

Por que esquecemos todas essas boas práticas que aprendemos em todos esses anos quando estamos diante de um RPA? Já vi robôs que, para acessar a internet, salvam nosso nome de usuário e senhas em um ".ini" como texto, expondo nossa segurança. Cada robô gera, na mesma empresa, um log de diferentes formatos localizados em diferentes lugares que também, quando conseguimos encontrar (porque ninguém sabe onde estão), não contêm nenhuma informação valiosa.  "Foi encontrado um problema" ... o que é isso? Codificações incertas e desordenadas que pouco atendem aos padrões mínimos de um bom design, com altíssimos custos de manutenção e muito pouco valor para a nossa organização e se gerar valor, com certeza, será desde que nenhuma mudança tenha que ser feita.

Quantas vezes já ouvi falar que os robôs chegaram e agora a gente tem mais problemas, ou que o robô não faz o que devia e vira uma máquina enchendo de pó num canto sem funcionar ou até mesmo quando chamam o suporte, eles avisam que o problema não é o robô. O que acontece é que não há conexão com a internet ou que a senha expirou ou outra coisa que, se você tivesse usado uma boa prática de design, não teria se deixado levar pelas circunstâncias.

Os desenvolvedores estão sempre codificando de forma positiva, isto é, pelo caminho mais feliz. A maioria das ações são pensadas em fazer e fazer e fazer, mas o que acontece se a condição do caminho feliz não ocorrer? O que acontece se não houver conexão com o sistema que o robô deseja usar? Nós pensamos sobre as ações a seguir? Ou apenas geramos uma mensagem (no melhor dos casos) em um log e que pouco diz sobre o problema, ou o que é pior, que descobrimos quando o problema surge muito mais tarde, quando não podemos mais fazer nada. Os desenvolvedores estão fazendo o que pedimos a eles e não estamos focados em projetar bons fluxos de processo para serem robotizados posteriormente.

Se um robô substitui o que uma pessoa faz, vamos fazer o que uma pessoa faria. Se detectarmos algum problema, enviamos um email para o responsável da área, se algo não funcionar, geramos um "ticket" no sistema de atendimento do problema, acendemos a luz, mas façamos alguma coisa.

Isso é o que acontece e acredito que não devemos entrar em uma máquina do tempo para viajar ao passado, mas sim ao contrário. Criar bons robôs para viajar mais longe no futuro, realizar uma verdadeira revolução nas organizações, alcançar o desejo de transformação digital, melhorar a eficiência, reduzir custos, ter clientes mais felizes a cada dia pelo bom serviço da nossa empresa.

Nosso foco é a incorporação de robôs e não a automação de processos.

Um robô é um programa, sim, é um programa como qualquer outro, veremos outra vez qual é a diferença entre um programa de robô e um programa "tradicional", mas que ambos são um programa, não há dúvida sobre isso. Então, vamos começar aplicando o que a humanidade aprendeu em todos esses anos para fazer um bom software, que com certeza sempre pode ser aprimorado, mas se compararmos com 30 anos atrás, temos grandes avanços.

Vamos definir regras universais para nossas robotizações, padrões, não importa se usamos uma ou outra ferramenta ou simplesmente usamos uma linguagem. Vamos definir segurança, infraestrutura, mnemônicos, e como gerar uma mensagem de erro e o seu conteúdo. Precisamos também identificar quem serão os responsáveis para que sejam informados sobre os problemas ocorridos e desse modo poderem agir imediatamente e chegaremos de forma clara e a maneira evidente de que nosso robô tem um problema, etc. Eu não estou dizendo nada de novo certo? Bem, é isso que quero dizer com esta máquina do tempo que nos leva a um momento em que não queremos estar.

Não procuro gerar polêmica, mas procuro gerar uma reflexão genuína para que essa abordagem maravilhosa da robotização gere valor para nós.

Meu maior conselho é antes de pensar em ferramentas ou linguagens para construir um robô, vamos simplesmente definir um ecossistema que seja sustentável para nossa empresa, que permita uma diversidade de ferramentas e linguagens, mas com regras claras teremos robôs muito “saudáveis” e ao invés de construir Robôs como nosso objetivo, que o objetivo seja definir os processos em sua completude. Use a técnica que quiser, com isso você verá que "quase" independente da ferramenta, seus robôs serão de uma ajuda maravilhosa para a sua organização e não uma dor de cabeça.

Se você já possui um conjunto de robôs operacionais em sua organização, use essa experiência para gerar padrões e se não organizar pequenos experimentos de robotização (1 a 2 semanas) e use essa experiência para iniciar um padrão para implementação de robotização. Lembre-se que um “padrão” não é um elemento estático, ele sem dúvida irá evoluir e deve evoluir, não vamos perder de vista a melhoria contínua. Com isso, quando você for robotizar, seja com equipes internas ou externas, poderá compartilhar a linha de base de seu padrão considerando todos os aspectos que devem ser respeitados para sua organização e você terá um melhor resultado.

O que você prefere, 1 erro que se repete 1.000 vezes ou 1.000 erros diferentes? O erro faz parte do ciclo de vida de qualquer solução, podemos gerenciá-los com base em nossos padrões, aprendemos com eles e o benefício é imenso. Se não os gerenciarmos, vamos repeti-los para sempre e não vamos evoluir para melhorar nossa robótica.

Com isso você pode aproveitar os benefícios de diferentes ferramentas e linguagens, não é necessário estar em uma única trincheira. Veja o que você precisa após projetar o processo e então decida qual é a melhor alternativa. Existem condições técnicas que permitem que algumas soluções funcionem melhor do que outras e, por fim, a Robotização não é a única forma de automatizar processos.

E quando você tem um grande número de robôs, como vamos governá-los?...ups!!!, vamos deixar essa para uma próxima oportunidade?