Em um relatório recente, a empresa de pesquisa de tecnologia Gartner previu que até o final de 2020, o mercado global de automação de processos (RPA) valerá US$ 5,97 bilhões. Nos próximos anos, espera-se que quase todas as empresas no mundo utilizem o RPA de alguma forma.
Nas palavras do arquiteto de software Louis Srygley, “Sem requisitos ou design, a programação é a arte de adicionar bugs a um arquivo de texto vazio”. Por mais que se tente dizer que não, para qualquer tipo de programação, uma documentação eficiente, na quantidade adequada, quando bem aplicada, é uma das chave para o sucesso. Com o RPA, não é diferente.
De acordo com o ciclo de vida de desenvolvimento RPA, a automação de processos começa com a criação de dois documentos fundamentais, o PDD e o SDD como parte da fase de planejamento, análise e design. Isso claro, de processos já selecionados e priorizados.
O PDD (Documento de Definição de Processo) contém informações sobre o diagrama de fluxo do processo AS IS e eventualmente do processo TO BE, uma vez que é natural fazermos melhorias no processo antes da automatização. É como um manual do usuário e é fornecido pelo usuário final ou analista de negócios. Este documento mostra o fluxo de alto nível do processo manual (como a sequência de etapas executadas como parte do processo de negócios, as condições e regras do processo).
Geralmente é usado como uma plataforma (uma base para desenvolvedores) a partir da qual a solução automatizada será projetada. Ele está incluído na fase de Planejamento e Análise do Ciclo de vida de Desenvolvimento do RPA.
Tipicamente deve conter:
- Nome do autor, aprovador e versão do documento;
- Lista de partes envolvidas: proprietário do processo, revisor do processo e especialista do processo;
- Processo AS IS: como mapa de processo, etapas de processo, lista de sistemas;
- Processo TO BE: desenho esperado do processo de negócio com melhorias;
- Entradas, saídas, registros e integrações;
- Regras de Exceções;
Adicionalmente, muitas vezes são adicionados outros elementos que trazem o histórico da fase de seleção e priorização:
- Critérios e Justificativas de Priorização;
- Tempo de Processo Atual;
- Volume de Dados Transacionados;
- Frequência de Execução do Processo;
- Número de FTE (Recursos Envolvidos);
- Percentual de Retrabalho/Desvio;
- Horários Atuais de Funcionamento do Processo;
- Principais KPIs;
- Estimativa de Esforço para Desenvolvimento;
- Business Case;
Então, isso já não é suficiente para iniciarmos o desenvolvimento? Bom, vale citar o velho ditado: “Ao falhar em se preparar, você está se preparando para falhar”. O mesmo vale para o desenvolvimento de RPA. Não pule nenhuma parte do estágio de planejamento.
Antes de começar a construir a automação, principalmente para processos complexos, é necessário planejar o desenvolvimento e o design da solução. Assim, trata-se de criar um processo automatizado inteligente (que crie novo valor) e não somente um mimético do processo manual, agora automatizado. Para isso, existe o SDD.
Um SDD significa Documento de Design de Solução e contém um relatório de design de alto nível que descreve como você pode implementar uma solução técnica para seu projeto. Ele é criado para cada processo de negócios automatizado com a tecnologia RPA. Este documento é preenchido pelo Arquiteto de Soluções RPA e Desenvolvedor RPA que automatiza o processo de negócios e revisado pelo Arquiteto de Soluções RPA antes de ser transferido para a equipe de operações. Ele está na fase de projeto do ciclo de vida de Desenvolvimento RPA.
O SDD repete algumas das informações do PDD, embora tenha em mente que o público é diferente. Enquanto o PDD é para proprietários de negócios, o SDD é para um público técnico: outros desenvolvedores, testadores e, o mais importante, para o departamento de TI ou quem for manter essa automação. O SDD tipicamente contém:
- Fluxo da automação;
- Fluxo das integrações com os diversos sistemas;
- Fluxos de envolvimento dos humanos;
- Infraestrutura Necessária;
- Gestão de acessos e senhas;
- Verificação dos itens de segurança;
- Pré-requisitos para automação;
- Tratamento de Exceções;
- Testes e Evidências de QA;
- Testes e Evidências de UAT;
- Configurações de Orquestração e Controle de Filas;
- Gestão dos Logs;
- Possíveis Integrações e Melhorias;
- Controle de Versionamento;
Claro, vale sempre lembrar: “Entre o terreno e mapa, fique sempre com o terreno”. Processos não são estáticos e nenhuma documentação, por melhor que seja é unânime. Dessa forma, transparência, colaboração, adaptação, comunicação e iteração são fundamentais para projetos de RPA que são prioritariamente orientados para as áreas de negócio. Assim, vale sempre lembrar de algumas boas práticas.
Parece óbvio, mas garanta que a equipe que começa e termina o projeto (desde o analista até o desenvolvedor) seja a mesma. Estabeleceça um período de Hypercare após o início de produção onde a equipe de desenvolvimento ainda é responsável por ajustes (acredite, eles serão necessários). Fragmente processos complexos em mais de uma PDD, sempre que possível.
Certifique-se de que sua solução seja fácil de seguir. Quando apropriado, adicione notas para explicar a funcionalidade dos componentes. Quando você está projetando soluções complexas, é fácil se perder. Registros claros ajudam a manter o controle do processo de construção e reduzem o tempo gasto na solução de problemas ou depuração.
Desenvolvedor, tente sempre pensar fora da caixa e antecipar problemas. Algumas regras de exceção são de domínio técnico por vivência e experiência e não necessariamente estarão na PDD ou SDD. Por exemplo, problemas de compatibilidade, acesso simultâneos e regras de segurança de TI não são de visibilidade do usuário e do analista de negócios.
Para garantir a operação contínua do robô, codifique a automação para lidar com exceções e reagir a elas de forma adequada (e inteligente, eventualmente com mais de uma opção). Alguns parâmetros mudam com o tempo: caminhos de arquivo, endereços de sites, e-mail e assim por diante. Evite codificá-los em sua solução sem considerar a facilidade de editar essas variáveis.
Por fim, testar sua solução é vital. Crie testes para cobrir o caminho feliz e as exceções e solicite seus dados de teste antecipadamente. Ter um ambiente de testes, preparado, com cobertura é fundamental. Claro, durante o desenvolvimento, teste os componentes individuais depois de configurá-los.
Muitas iniciativas de Transformação Digital falham por falta de planejamento. RPA é uma alavanca poderosa e cada vez mais está na mão de usuários finais. Isso pode gerar uma falsa sensação que boas práticas e governança não são importantes, cuidado. É muito importante compartilharmos boas e melhores práticas e refletirmos sobre o processo de desenvolvimento do início a fim, sempre com melhoria contínua. Como dizia meu avô, “Vamos devagar porque temos pressa”. Ou como eu costumo dizer: “Mais planejamento, menos planos”.
