Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Com essa modularização é possível também definir usuários diferentes para que sejam gestores de cada parte do processo, gerando assim mais segurança para as informações.

Informações

Veja o exemplo em nosso repositório aqui.

Desenho do Processo

Raias

O desenho do processo no fluig deve sempre separar as tarefas conforme os papéis e esses devem ser representados por raias. No exemplo citado anteriormente sobre o workflow de compras, temos duas raias, uma onde ficam a(s) atividade(s) executada(s) pelo solicitante e outra onde ficam a(s) atividade(s) executada(s) pelo aprovador.

...

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

...

Hierarquia 2: Coordenador > Gerente > Diretor


 


Hierarquia 3: Gerente > Diretor > RH

...

Após finalizar a etapa de criação de solicitação, é gerada a seguinte: aprovação pelo coordenador:

 



Após a aprovação pelo coordenador, é gerada a seguinte: aprovação pelo gerente: 



Após a aprovação pelo gerente, é gerada a seguinte: aprovação pelo Diretor:

...

Na sequência, é apresentado um exemplo da utilização da aprovação técnica que precede uma aprovação por hierarquia. Neste caso, podemos supor que se está solicitando a compra de um notebook para um funcionário que irá entrar na empresa. A aprovação técnica poderia ser direcionada a alguém da área de infraestrutura (TI) e, após a aprovação desse usuário, passaria para aprovação financeira de coordenador, gerente e diretor, por exemplo. 


 


Ao mesclar a aprovação técnica com os outros tipos de aprovação é que acabamos gerando a complexidade dos workflows, pois em alguns momentos a aprovação técnica pode ser paralela aos outros tipos, em outros momentos predecessora, e assim por diante. Esse dinamismo entre os tipos de aprovação será apresentado mais adiante.

...

O tipo de aprovação por faixa de valores consiste na determinação dos aprovadores de um determinado documento, conforme o seu valor. Por exemplo, até um determinado valor é o coordenador que deve aprovar, acima desse valor e até um limite um pouco maior, o gerente que deve aprovar e, passando disso, a aprovação seria pelo diretor. Isto caracteriza uma aprovação por faixa de valores (alçada). Quando são níveis fixos de aprovação, pode ser desenhado o fluxo com o direcionamento no workflow, conforme abaixo:

 



Se as faixas de aprovações são dinâmicas, ou seja, não é possível definir quantos níveis de aprovação existirão antes da criação do documento, é necessário utilizar o recurso de “ad-hoc” para gerar as atividades em tempo de execução do workflow.

Por exemplo, imagine que no ERP existam essas regras descritas na tabela apresentada a seguir. Conforme o item criado na solicitação, as faixas de aprovação serão diferentes e, possivelmente os aprovadores de cada faixa, para cada item também. 


Item da SolicitaçãoFaixas de AprovaçãoAprovador da Faixa

Item X

De 0,00 até 1.000

Líder

De 1.000,01 até 5.000

Coordenador

De 5.000,01 até 999.999.999.9999,99

Gerente

 

Item Y

De 0,00 até 1.000

Líder

De 1.000,01 até 5.000

Coordenador

De 5.000,01 até 50.0000,00

Gerente

De 50.000,01 até 999.999.999.9999,99

Diretor

 


Item Z

De 0,00 até 999.999.999.9999,99

Diretor

 


Temos um nível de complexidade um pouco maior quando, para cada faixa de aprovação, ao invés de existir apenas um aprovador, existe uma hierarquia de aprovadores. Abaixo é detalhado um exemplo com essa situação: 


Item da SolicitaçãoFaixas de AprovaçãoAprovadores da Faixa
Item X   

De 0,00 até 1.000

Líder

De 1.000,01 até 5.000

Líder
Coordenador

De 5.000,01 até 999.999.999.9999,99

Líder
Coordenador
Gerente
 

Item Y

De 0,00 até 1.000

Líder

De 1.000,01 até 5.000

Líder

Coordenador

De 5.000,01 até 50.0000,00

Líder

Coordenador

Gerente

De 50.000,01 até 999.999.999.9999,99

Líder

Coordenador

Gerente

Diretor

 


Item Z

De 0,00 até 999.999.999.9999,99

Líder

Coordenador

Gerente

Diretor

 


Neste caso, após a atividade "Criar Solicitação" é necessário gerar, por meio de uma atividade “ad-hoc”, todas as aprovações que devem ocorrer. A seguir é apresentado um exemplo de como ficaria uma solicitação com os três itens do exemplo acima: 


 


Paralelismo de Atividades

...

Neste caso, tem-se basicamente a mesma estrutura apresentada anteriormente para hierarquia, com a diferença de que podem ser gerados fluxos de atividades que podem ocorrer de forma paralela, sequencial ou com uma mescla dos dois no mesmo workflow. Existe a opção de criar todas as atividade do “ad-hoc” já no momento de iniciá-la no workflow, ou então, gerar de forma incremental na medida em que forem ocorrendo. Utilizando o mesmo exemplo que já vinha sido discutido e supondo que a solicitação de compra precise passar por uma hierarquia de aprovadores e, além disso, por uma aprovação técnica. Caso esses dois tipos de aprovação tenham necessidade de ocorrer de forma paralela, o fluxo ficaria conforme abaixo: 


 


Se as atividades estão sendo geradas sob demanda, inicialmente seriam geradas “Aprovação Líder” e “Aprovação Técnica” e as demais conforme o workflow vai evoluindo. Assim como na questão da hierarquia, é possível também, gerar já no início todas as tarefas que serão executadas no “ad-hoc”. A quantidade de fluxos paralelos é variável conforme a necessidade da rotina de negócio. Neste caso pode existir apenas um fluxo ou diversos.

...

O exemplo apresentado na sequência é uma mescla da utilização de vários recursos comentados até o momento. Neste caso, tem-se a criação de uma solicitação de compra com dois itens e cada um desses itens possui uma estrutura de aprovação diferenciada. 


 


Considerando que o processo “Aprovação da Solicitação” é um sub processo do principal, são geradas duas instâncias dele, uma para aprovação do Item X e outra para aprovação do item Y. Neste sub processo que existe a atividade de “ad-hoc”, para o Item X, é gerada uma hierarquia de aprovadores e, paralelamente, uma aprovação técnica para um único aprovador. Já para o Item Y, o tipo de aprovação será uma lista de usuários aprovadores e, quando o primeiro aprovar, já se considera a atividade como aprovada - neste caso, seria utilizado o recurso de atividade conjunta.

Dentro da atividade de “ad-hoc” existe um mecanismo para que seja possível cancelar tarefas pendentes (desconsiderá-las) e passar para uma próxima tarefa que não seja parte do “ad-hoc”. Por exemplo, nesta situação apresentada, se todas as tarefas do “ad-hoc” tivessem sido geradas já no início, ao chegar na atividade “Aprovação Coordenador” e o usuário rejeitar, é necessário encaminhar o workflow para a próxima tarefa após o “ad-hoc” e cancelar outros fluxos paralelos que estejam em andamento.

 



Pelo serviço é possível identificar no “ad-hoc” qual tarefa está em execução no momento e identificá-las pelos Ids gerados.

...

Dentro do recurso do “ad-hoc” não é possível estabelecer fluxos conforme o apresentado abaixo, onde o workflow começa com somente uma atividade, mas em determinado ponto é necessário gerar um paralelismo de atividades e depois retorna a uma única atividade novamente. 



Nomenclatura dos Workflows 

...

Como é no processo de aprovação que essa questão de nomenclaturas é mais importante, abaixo estão listados os principais documentos que passam pelo processo de aprovação e o nome de workflow a ser utilizado:

 


Nome WorkflowDescrição
Aprovação de Solicitação de CompraUtilizado para aprovar uma compra de material.
Aprovação de Requisição de Estoque/ArmazémUtilizado para aprovar uma requisição de material do estoque ou armazém.
Aprovação de Solicitação de ServiçoUtilizado para aprovar solicitações de serviço.
Aprovação de Solicitação de CotaçãoUtilizado para aprovar solicitação de cotação de material ou serviço.
Aprovação de Cotação de CompraUtilizado para aprovar cotações de compra realizadas pelo comprador.
Aprovação de Pedido de CompraUtilizado para aprovar pedidos de compra.
Aprovação de Contrato de CompraUtilizado para aprovar contratos de compra.
Aprovação de CréditoUtilizado para aprovação de crédito. Ex.: de cliente, de pedido de venda.
Aprovação de TítulosUtilizado para aprovação de títulos (financeiro).
Aprovação de Antecipações de FornecedoresUtilizado para aprovação de antecipações de fornecedores.
Aprovação de Pagamento Extra FornecedoresUtilizado para aprovação de pagamento de extra fornecedores.
Aprovação de PagamentosUtilizado para aprovação de pagamentos.

...


Gestão do Workflow

Usuários Substitutos

...