Blog da iProcess - Compartilhando conhecimento em BPM e RPA

Como documentar funcionalmente o processo de negócio como requisito de software

Na automação de processos, os processos de negócio são definidos e otimizados a fim de serem executados sobre uma arquitetura de sistemas informatizada.

No artigo Benefícios da Automação de Processos do blog da iProcess, tratamos dos benefícios e vantagens da automação de processos, estabelecendo uma visão dos ganhos obtidos quando se automatiza um processo. Porém, alguns cuidados devem ser tomados para escolher um processo a ser automatizado e estabelecer o nível de detalhamento necessário do processo para tal, tendo como objetivo automatizar processos com tarefas que possam efetivamente demonstrar bons resultados. Em Estudo de Caso: Automatizar o processo (ou não)? Eis a questão! exploramos esta questão através de um estudo de caso.

As etapas de modelagem na transformação de um processo

Nos projetos de implementação de BPM, o ciclo BPM a ser seguido inclui a análise (AS IS) e o redesenho (TO BE) dos processos, antes de seguir para a etapa de implementação (TO DO). Desta forma, garante-se que o cenário atual do processo na organização foi adequadamente estudado e todas as necessidades de melhoria no processo foram devidamente contempladas.

O artigo BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado aborda este tema, incluindo aí os riscos envolvidos em um projeto em que se parte diretamente para a etapa de implementação (TO DO), sem passar pelas demais. Isto porque é na etapa de TO BE, em que há a proposição de melhorias no processo e são definidos os requisitos de software que irão compor a solução automatizada. Já falamos sobre esta ligação no artigo O que BPM tem a ver com requisitos de software? Tudo!, enfatizando que os requisitos de software são identificados a partir do processo.

Documentando a modelagem do processo para automação (TO DO)

Passadas todas estas fases, chega a hora da implementação do processo. O processo e os requisitos de software complementares serão detalhados funcionalmente (TO DO) e implementados pela equipe de desenvolvimento. E aí entra em cena a Especificação Funcional do processo. Ela especifica o fluxo a ser automatizado no BPMS e sua estrutura de dados, regras para identificação de participantes e comportamento de cada componente.Resumidamente, a Especificação Funcional deve atender aos seguintes objetivos:

  • Concentrar as informações do processo de negócio necessárias para a automação do processo;
  • Utilizar linguagem que deve ser de fácil compreensão pelo público-alvo;
  • Fornecer informações suficientes para que o projetista possa desenvolver a especificação técnica do processo;
  • Servir de referência para o desenvolvimento e homologação da solução.

Temos encontrado, ao longo dos projetos de automação de processos em que a iProcess atua, alguns clientes que já possuem uma metodologia, utilizam ferramentas e templates para documentar processos automatizados, enquanto outros não possuem nada definido. Nas organizações que já tenham adotado uma metodologia de desenvolvimento com documentação funcional dos requisitos, é comum encontrarmos documentos como Casos de Uso, Especificações de Interface, Especificações de Serviço ou de Regras de Negócio. Nos projetos de automação de processos, é comum que os requisitos se estendam além da programação do fluxo no BPMS, envolvendo o desenvolvimento ou customização de componentes adicionais ao processo, como aplicações de apoio, cadastros de backoffice e serviços de integração com outros sistemas. Para estes requisitos, os documentos já adotados pela TI continuam sendo bastante apropriados. 

 Assim, a Especificação Funcional do Processo (o modelo TO DO) vem para complementar a documentação do sistema definindo funcionalmente o processo de negócio, e requer um detalhamento de como o fluxo do processo se comportará ao ser automatizado. São informações importantes neste modelo:

  • Diagrama do processo automatizado;
  • Modelo de dados do processo;
  • Identificação de usuários ou grupos de usuários participantes do processo (Papéis);
  • Formulários do Processo;
  • Especificação dos componentes do processo, que são eventos, tarefas humanas e automáticas, notificações/envios de email, controles de tempo, gateways, subprocessos, regras de negócio e sensores de indicadores;
  • Definições de interface para as atividades humanas;
  • Referências a serviços de outros sistemas;

Esta especificação deve ser realizada por um Analista de Processos e Sistemas, ou um analista de sistemas que tenha desenvolvido uma visão de processos, horizontal aos sistemas, e que conheça as capacidades de implementação do BPMS adotado pela empresa

O Analista de Processos e de Sistemas, pode encontrar alguma dificuldade em estabelecer a melhor forma de como escrever utilizando uma linguagem de fácil compreensão pelo usuário e ainda assim fornecer informações suficientes para que sirva de referência para a elaboração da especificação técnica e o posterior desenvolvimento da solução. Uma sugestão nesta situação é o alinhamento com os responsáveis pela aprovação do documento no cliente, para estabelecer qual será o nível de detalhamento da Especificação Funcional do processo, a fim de definir se haverá necessidade de utilizar documentos complementares mais técnicos para a equipe de desenvolvimento, ou em mais alto nível para a equipe de negócio.

Temos observado que, às vezes, o cliente opta por realizar uma “tradução” da especificação para a área de negócio ou absorver para si a aprovação do documento. Quanto mais precisa for a Especificação Funcional do processo, menos problemas de entendimento tendem a ocorrer entre a expectativa do cliente e o que está sendo desenvolvido. Isto porque as etapas de desenvolvimento e homologação dos processos vão utilizar estas informações, garantindo assim, que o que foi definido e aprovado pelo cliente seja entregue.

Cabe aqui salientar que a Especificação Funcional do processo, assim como de sistemas, não fica “congelada”, sem receber as atualizações que ocorrerem no escopo do projeto durante o seu ciclo de vida. Ajustes na documentação funcional podem ser necessários após a finalização da etapa de especificação funcional por diversos motivos e devem ser realizados, sempre que necessário, para que se mantenha a consistência entre o que foi especificado e o que foi desenvolvido. E neste caso, a gestão de mudanças do projeto é que tratará desta atualização.

Se este assunto lhe interessou, no nosso curso iPE03 – Modelagem de Processos para Automação, reservamos um capitulo inteiro para tratar deste assunto, inclusive com exercícios práticos.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MAIS VISTOS

Como transformar as ideias de mudança para um processo TO BE em ações efetivas, controladas... (continuar lendo)
Veja agora as ações que foram realizadas através das doações de todos os participantes deste... (continuar lendo)
Participe deste evento exclusive e gratuIto e se prepare para as transformações que IA irá... (continuar lendo)

Inscreva-se na nossa Newsletter

seers cmp badge