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”.
Gilberto Strafacci Neto
Chief Operating Officer da Practia Brasil (www.practiaglobal.com.br) e Senior Partner do Setec Consulting Group (www.setecnet.com.br). Master Business Essentials CORe Program pela Harvard Business School, MBA em Liderança e Inovação, Engenheiro Mecânico pela Escola Politécnica da Universidade de São Paulo, Master Black Belt, Agile Coach, Design Thinker, Manager 3.0, Certified Six Sigma Master Black Belt pela American Society for Quality (ASQ) e Certified Scrum Master pela Scrum Alliance e Facilitador Certificado LEGO® SERIOUS PLAY® (Ver PERFIL).