...

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.

Image Modified

Sub Processos

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. Existe uma forma em que o sub processo pode acessar dados do formulário do processo pai, por meio de funções chamadas por personalizaçã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.

...

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.

Hierarquia

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.

...

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.

Aprovação Técnica

A aprovação técnica é um tipo de aprovação que normalmente é utilizada em conjunto com outros tipos. Ela serve para que um usuário especialista possa avaliar se as especificações do que está está sendo solicitado/comprado está de acordo com as necessidades da empresa, com os requisitos técnicos necessários, entre outras análises que os aprovadores financeiros não tem condições de avaliar. Conforme as regras da empresa, esse tipo de aprovação ocorre paralelamente aos outros tipos de aprovações ou, então, pode ser pré-requisito para os demais tipos de aprovação.

...

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 da 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.

Lista de Aprovadores ou Consenso

Esse tipo de aprovação consiste em enviar um processo ou um documento para uma lista de usuários avaliarem. Conforme as regras do ERP, desta lista de usuários, um determinado número precisa aprovar para que ele seja considerado efetivamente como aprovado. A lista de aprovadores ou consenso é utilizada quando se tem um grupo de usuários que podem aprovar um determinado documento, sem necessariamente nomear um aprovador. Por exemplo, o documento deve ser aprovado por um dos diretores da empresa. Neste caso, é gerada uma lista de usuários aprovadores, onde estão todos os diretores da empresa. Quando o documento for para aprovação, todos os diretores receberão essa pendência, porém, assim que o primeiro aprovar, o documento será considerado como aprovado, eliminando a necessidade dos demais diretores aprovarem.

Para utilizar esse tipo de aprovação no fluig, pode ser utilizada uma atividade comum, marcando como sendo uma atividade conjunta. Dessa forma, esse tipo de aprovação também só gera complexidade ao ser utilizado em conjunto com outros tipos de aprovação.

Aprovação por Faixa de Valores (Por Alçada)

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:

...

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.

...

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  Workflows

...

Para que os usuários que utilizam 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.

...

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.

...