A parceria entre os processos automatizados e os sistemas já existentes em uma organização

Podemos dizer, a partir da experiência da equipe iProcess em automação de processos, que os processos automatizados e os sistemas informatizados das organizações não competem entre si, eles formam uma parceria, se complementam. Dizemos isto porque são nos sistemas já existentes nas organizações que os processos obtém as informações necessárias para a execução dos fluxos de trabalho, utilizando-se para isto de uma camada de integração. Daí o motivo de acreditarmos que ambos se complementam.

Os sistemas já existentes, que também chamamos de legado, não são descontinuados ao serem integrados ao processo automatizado. O processo será responsável pela conexão entre estes sistemas e os usuários do processo. Através do BPMS (Business Process Management Suite ou System), uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Assim, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes.

Desta forma, os sistemas se preocupam com o cadastro, atualização e consulta das informações armazenadas em base de dados e os processos com a sua distribuição, tendo o foco na sequência de etapas, prazos, distribuição das atividades, integridade do processo e em fornecer o melhor ambiente possível para que as atividades sejam executadas. Em alguns casos, se faz necessário o armazenamento das informações ao longo do processo, mas são informações específicas para o contexto das instâncias do processo, que servem para controle de estado do fluxo e logs de atividades, por exemplo.

Quando se automatiza um processo, na etapa de levantamento das informações, é que verificamos como a parceria entre os sistemas já existentes na empresa e o processo utilizando BPMS se dará. Algumas das informações levantadas nesta etapa são:

  • Informações consumidas e informações geradas pelo processo, isto é, quais as informações que deverão ser recebidas pelo processo oriundas de sistemas e quais as informações que eventualmente deverão ser enviadas para gravação em sistemas existentes da organização, como, por exemplo, ERP, sistemas contábeis ou cadastros corporativos.
  • Pontos de integração, isto é, em quais atividades do processo deverão ser obtidas/geradas informações que alimentam os sistemas legados.
  • Como que o processo e os sistemas legados conversarão entre si, que normalmente ocorre através da camada de integração, utilizando serviços especialmente construídos para isto.

A implementação de BPMS nas organizações não deve ser orientada a substituir total ou parcialmente os sistemas atuais esperando-se que passe eventualmente a ser o repositório central das informações da organização. O BPMS não é a fonte principal das informações que estão sendo manipuladas, mas atua principalmente como integrador delas, buscando e enviando informações para outros sistemas durante a execução dos processos.

A iProcess disponibiliza em sua plataforma EAD mais informações sobre este assunto, através do Curso TDP – Transformação Digital Orientada a Processos.

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.