...

Para que seja possível utilizar os sub processos de forma efetiva, muitas vezes o processo principal precisa saber o que ocorreu no sub processo para direcionar o workflow. Por esse motivo é possível que ao término de um sub processo sejam recuperados valores de seu processamento.

Tipos de Aprovação e suas Representações no Workflow

Especialmente para workflows que representam a aprovação de algum tipo de documento/processo, existem algumas estruturas que são comuns, por isso foram  estabelecidos alguns padrões a serem seguidos ao modelar esse tipo de workflow.

...

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.

Aprovação Padrão

 A aprovação que aqui chamamos de padrão é a aprovação mais simples que temos, onde um documento é enviado para um determinado usuário aprovar. Basicamente, a mesma ideia de que a aprovação técnica apresentada anteriormente, com a diferença de que não há essa responsabilidade técnica da aprovação. Por exemplo, em uma empresa, onde não existe uma hierarquia de aprovadores e complexidade no processo de aprovação, poderia ser criada uma aprovação padrão, que cairia somente para o diretor da empresa aprovar.

...

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

Conforme citado anteriormente, todos os tipos de aprovação podem ser utilizados em conjunto e neste ponto teremos que tratar o paralelismo de atividades e flexibilidade no momento que devem ser executadas. Ou seja, tratar no workflow todo o dinamismo de parametrizações que o ERP permite.

Quando houver a necessidade de utilização de atividades paralelas, se elas tiverem uma estrutura fixa, pode-se utilizar o recurso de “Fork-Join” para tratar o pararelismo no próprio desenho do workflow. Porém, quando o paralelismo for dinâmico, ou seja, não há como prever antes do workflow estar em andamento se haverá paralelismo entre as atividades ou quantos fluxos de atividades paralelas serão utilizados, o recurso é utilizar uma atividade “ad-hoc” para contemplar a situação.

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:

Image Added

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.

Para cada atividade gerada dentro do “ad-hoc” não existem todas as opções de mecanismo de atribuição que existem para as atividades comuns. Existem duas opções: definir que a atividade será para um usuário em específico ou para uma lista de usuários. No caso da lista, todos os usuários a recebem para executá-la. Caso exista a necessidade de criar uma atividade de consenso, o ERP controla isso. Não é possível atribuir tarefas “ad-hoc” para grupos.

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.

Image Added

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.

Image Added

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

Dessa forma, é possível ter o controle de informar ao workflow que uma atividade foi realizada pelo ERP e precisa mover o workflow para uma outra tarefa. Da mesma forma é possível informar ao workflow que uma atividade foi realizada e é necessário gerar a próxima tarefa. Um exemplo disso seria o coordenador aprovando a solicitação pelo ERP: o Fluig precisa ser avisado disso para que possa gerar a próxima tarefa que seria a “Aprovação pelo Gerente”.

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.

Image Added

Nomenclatura dos Workflows 

Para que os usuários que utiliza o Fluig possam ter a sensação de utilizarem uma interface única para todos os ERPs, é necessário haver uma padronização na nomenclatura dos workflows.

Essa necessidade é visível quando se imagina um usuário aprovador de documentos que sejam originários de diversos sistemas diferentes. Por exemplo, um diretor que aprova pedidos de compra de várias filiais e cada filial utiliza um ERP diferente. Se não houver uma padronização, esse diretor pode receber vários workflows com nomes distintos, porém todos representando a necessidade de aprovar um pedido de compra. Exemplos que poderiam ocorrer:

• aprovação de pedido de compra;
• aprovação de necessidade de compra;
• análise de pedido de compra;
• aprovar pedido.

Para que isto não ocorra, deve ser seguida a seguinte nomenclatura: substantivo + documento/descrição + (complemento). A parte do complemento é opcional e serve para informar uma especialização do workflow. Por exemplo, existe o workflow de “Aprovação de Pedido de Compra”, porém para alguns ERPs pode existir diferentes pedidos de compra, então poderia ser utilizado o complemento “Aprovação de Pedido de Compra (Emergencial)”.

Alguns exemplos de nomes de workflows:

• aprovação de pedido de compra;
• aprovação de pedido de compra (Emergencial);
• criação de pedido de compra;
• atendimento de necessidade de compra.

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:

Gestão do workflow

Usuários Substitutos

O Fluig possui um cadastro de usuários substitutos que servem para todas as atividades realizadas dentro dele.  Porém, conforme a necessidade de negócio do workflow criado, esses substitutos não podem ser utilizados de forma genérica em todo o Fluig. Por isso há uma forma de definir usuários substitutos por tipo de workflow.

Esses usuários substitutos podem ser cadastrados no próprio Fluig ou sincronizados por serviços disponibilizados. Para cada workflow criado, é importante haver uma análise para definir se o processo em questão tem a necessidade de definir substitutos específicos para o tipo de workflow ou se pode utilizar os do Fluig. Caso seja necessário que os usuários substitutos sejam por workflow e o ERP controle isso, é possível remover a permissão do item de menu que define esses usuários substitutos (mas neste caso o usuário não pode cadastrar substitutos para nenhum workflow em específico).

Gestores de Processo

Os gestores de processo são os usuários que possuem autonomia para realizar qualquer movimentação dentro de um workflow criado. Por isso, é importante cautela ao definir quem serão esses usuários para cada tipo de workflow.

Central de Tarefas

Através da Central de tarefas o usuário terá acesso a todas as suas pendências a serem executadas. Para que seja possível identificar rapidamente a atividade a ser executada (documento a ser aprovado, ou outra atividade) são necessários filtros que permitam além de identificar os documentos por processo de workflow, opções que permitam localizar um workflow em específico. Por exemplo, em uma indústria, caso ocorra problemas de falta de matéria-prima, e urgência na obtenção da mesma, o comprador faz o pedido de compra e envia para aprovação dos superiores. Logo em seguida, para agilizar o processo, esse comprador entra em contato com o aprovador para solicitar prioridade na aprovação. O comprador solicita a aprovação do pedido “X”, normalmente ele não sabe o número da solicitação gerada no Fluig para informar diretamente ao seu superior. O aprovador como possui diversos outros pedidos pendentes de aprovação, tem a necessidade de encontrar esse workflow de forma simples e ágil. 

Explicação. Exemplo para links e anexos.

...