Histórico da Página

...

Um exemplo para ilustrar essa situação seria o workflow do processo de compras (aquisição de material). De forma simplificada, pode-se definir duas atividades para este processo: solicitar compra (executada por um solicitante) e aprovar compra (executada por um aprovador). Se for criado um único workflow “Processo de Compra” com essas duas atividades, sem criar sub processos, perde-se a flexibilidade de gerar uma solicitação de compra pelo ERP, e apenas aprovar pelo Fluig, por exemplo. Com os sub processos, tem-se um workflow de “Aprovação de Compra” e outro como “Processo de Compra” que utiliza o anterior como como um sub processo. Com essa arquitetura o usuário pode criar uma solicitação pelo Fluig, utilizando o workflow de “Processo de Compra” ou então criar a solicitação pelo ERP e a aprovação será realizada pelo Fluig utilizando o workflow “Aprovação de Compra”.

...

Com a utilização dos sub processos, há também a vantagem de que não existirá um único formulário para todo um processo de negócio, facilitando assim futuras manutenções e desenvolvimentos. Existirá Existe uma forma em que o sub processo pode acessar dados do formulário do processo pai, por meio de funções chamadas por customização que são disponibilizadas para isso. Uma vez que tenha sido criado um sub processo, o processo pai também passa a ter acesso aos dados do formulário do sub processo.

...

Ao identificar que um workflow deve possuir uma hierarquia de aprovadores, a primeira coisa a ser verificada é se essa hierarquia é fixa ou dinâmica. Por exemplo, supondo que uma solicitação de compra deva passar sempre por três níveis de aprovação (três pessoas diferentes), pode-se dizer que essa é uma hierarquia fixa. Neste caso, é possível definir o processo desenhando as atividades de forma fixa no workflow, conforme apresentado abaixo. Mesmo que os usuários que aprovarão sejam diferentes para cada nível, conforme o item ou área, ainda assim a hierarquia é fixa no workflow.

Quando existir uma atividade que necessita passar por uma hierarquia dinâmica de aprovadores, ou seja, mudam os usuários, as ordens de execução, quantidade de usuários entre outras variações, deve-se utilizar o recurso de “ad-hoc”. Com esse recurso é possível gerar as atividades conforme a necessidade, de forma sequencial ou paralela. Na sequência, um exemplo do workflow de compras, que possui as tarefas de criação da solicitação e aprovação. A atividade “Aprovar Solicitação” pode variar, por exemplo, conforme o item e passar por hierarquias diferentes. A seguir são apresentados alguns exemplos.:

Hierarquia 1: Líder > Coordenador > Gerente > Diretor

...

Como se pode observar, no final da execução de cada tarefa é executada a lógica para verificar se existe uma próxima a ser realizada. Neste exemplo, ao finalizar a etapa de aprovação pelo diretor, não há mais tarefas a serem geradas e então o workflow é finalizado. Se houvessem mais tarefas a serem executadas após o “ad-hoc”, elas seriam executadas na sequência, após finalizadas as tarefas do “ad-hoc”. 

Caso exista um processo onde a hierarquia de aprovadores ou atividades seja dinâmica mas já é conhecida no início do fluxo, é possível que, ao executar a atividade “ad-hoc”, já sejam geradas todas as tarefas. Esse recurso deve ser utilizado no caso de processos dinâmicos onde não há grande possibilidade de mudanças das atividades a serem executadas. A vantagem é que neste caso é possível visualizar todas as atividades do “ad-hoc” no momento em que ela é iniciada.

...