Histórico da Página
...
Este documento tem como objetivo descrever como foi desenvolvido desenvolvida e implementado implementada a solução técnica para realizar a experiência #2 que consiste na internalização de funcionalidades dos produtos do Totvs Financial Services para o Fluig.
da TOTVS Financial Services para o Fluig.
Entendendo a Experiência #2
Integração com o Gestão de Risco
Conhecido pela internalização de funcionalidades dos produtos da TOTVS para o Fluig, a experiência de uso sugere a integração do Sistema de Gestão de Rísco de Crédito (GRISCO) com o Sistema Fluig ECM, com a finalidade de automatizar o processo de aprovação de proposta no módulo Gestão de Risco. Utilizando o engine de Workflow/BPM do Fluig, os Analistas de Negócio terão mais autonomia para configurar o workflow da esteira de crédito do GRISCO conforme as necessidades funcionais de cada cliente. O Sistema GRISCO continua sendo o provedor do serviço de manutenção dos dados da proposta, enquanto o Fluig o gestor e motor de execução do processo de concessão de limite, que será executado e modelado através do Fluig. O módulo GRISCO possui um engine nativo como motor de workflow do fluxo de aprovação de propostas que será substituido pelo Fluig workflow/BPM, integrando com o social. Podemos ver na figura abaixo a representação do processo do GRISCO pelo Fluig Diagrama. O BPM busca através de um formulário informações do GRisco, que é usado como repositório para o fluig.
| Aviso |
|---|
| Obs: Para que o GRISCO contemple o Workflow do Fluig é necessário que as configurações de uso do GRISCO sejam desativadas. |
O processo define os grupo e eventos do processo. Um grupo de evento no GRISCO representa um agrupador de atividades, podemos associar um grupo de evento com um subprocesso.
Abaixo a descrição do processo ilustrado na figura para um melhor entendimento da integração com o GRisco.
1 | Solicitar Proposta Limite O usuário acessa o Fluig e inicializa um processo de Concessão de Limite de Crédito.
|
2 | Registrar Proposta O usuário assume a atividade para registrar os dados da proposta. O Fluig direciona o usuário para a tela de iteração com o workflow do processo. O formulário do processo abre a tela de cadastramento de proposta do Sistema de Risco. Neste momento o usuário precisa iteragir com os dois Sistemas, no GRISCO para entrar com os dados da proposta e no Fluig para avançar a atividade. Obs: Neste ponto é necessário implementar uma validação no evento de finalização da atividade para verificar se o usuário realmente cadastrou a proposta no Sistema de Risco.
|
3 | Executar Motor de Crédito Esta atividade faz uma requisição ao Motor de Crédito, o retorno do Motor de Crédito é avaliado em uma expressão automatica para determinar o caminho do processo. O retorno do motor é exatamente como ocorre atualmente entre GRISCO e Motor de Crédito (Intellector). O Motor de Crédito retorna uma sigla que define quais os grupos de eventos que serão gerados para a proposta. |
4 | Registrar Pendência de Empréstimo Subprocesso que definie quais serão as atividades de interação humana. Estas atividades são representadas por eventos no GRISCO e estes eventos serão desativados enquanto estiver em interação com o Fluig. |
5 | Registrar Pendência de GRAVAME Nesta atividade o usuário apenas registra a observação e avança o processo. Em todas as atividades do processo o usuário poderá modificar as informações da proposta acessando o Sistema GRISCO por dentro do Fluig. O formulário do processo irá exibir os dados da proposta em todas as atividades, através da tela do Sistema de Risco. |
6 | Finalizar formalização Esta atividade tem por finalidade consumir o serviço do Sistema de Risco para finalizar o ciclo de vida da proposta, o propósito é notificar o GRISCO do resultado do Workflow de concessão de limite. O resultado é obtido conforme o caminho lógico percorrido pelo Fluig. |
Estrutura Workflow Fluig
Tem o objetivo de fazer com que usuários, clientes, fornecedores e parceiros participem ativamente da empresa, administrando os processos, gerenciando fluxos de trabalho, desenhando e evoluindo processos simples e complexos, sustentados por formulários eletrônicos e administrados por regras parametrizáveis, interagindo com outros sistemas e aplicativos da empresa.
Na versão 11, iniciamos a externalização dos fluxos de aprovação dos ERPs para o engine workflow/BPM do Fluig que possui aplicativo móvel como sua interface para suportar as aprovações. Cada atividade no Workflow corresponde a uma etapa de aprovação e a próxima etapa só poderá ser alcançada se a anterior tiver sido aprovada. O processo possui tomadas de decisão, ou seja, toma caminhos diferentes conforme os produtos selecionados para concessão do limite de crédito. Se a proposta de crédito tiver os dois produtos Garantia e Finame, significa que serão criadas duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade seja aprovada, e o processo não atingirá seu final. Imagem do workflow pode ser vista a seguir no tópico Desenho do Processo no Fluig.
Limitação do escopo
Esteira de Crédito
...
Conforme a descrição de escopo do documento de declaração de trabalho das experiências de uso, o texto sugere que o motor de aprovação de limite de crédito seja todo executado no Fluig, substituindo o motor que existe atualmente no GRisco, mantendo o mesmo como sistema de background para persistência e repositório da proposta no seu estado final, ou seja, aprovada ou negada. Foi, então, selecionado um processo real do cliente Moneo e tomado como referência para ser reproduzido no Fluig. Algumas características importantes acerca do processo escolhido serviram para limitar o escopo do desenvolvimento:
- O processo de proposta de limite de crédito possui atividades dispostas em série, sendo que cada atividade corresponde a uma etapa de aprovação e a próxima etapa só poderá ser alcançada se a anterior tiver sido aprovada. Cada atividade no Fluig pode ser entendida como um evento no GRisco;
- O processo possui tomadas de decisão, ou seja, toma caminhos diferentes conforme os produtos selecionados para concessão do limite de crédito. Se a proposta de crédito tiver os dois produtos, Garantia e Finame, significa que será criada duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade (proposta) seja aprovada, o processo não atingirá seu final;
- Não está previsto atividade conjunta, que são aquelas atividades que possuem vários aprovadores que precisam chegar a um consenso.
Desenho
...
do processo no Fluig
Para desenhar o processo, foi utilizado o TDS (Totvs Developer Studio). Trata-se de uma ferramenta baseada no Eclipse com plug-ins para desenvolvimento no Fluig. Dentro do projeto foi criado o desenho do processo conforme ilustração abaixo:
O processo inicia com a seleção do cliente para qual a proposta será criada e preenchimento do formulário com os dados da proposta: seleção dos produtos para concessão de limite, inserção de participantes (avalistas), bens e garantias. Assim que o formulário é submetido, o processo cai na primeira atividade, que é o Parecer Comitê Análise. Esta atividade possui um mecanismo de atribuição definido por Grupo. Mais adiante será explicado sobre os diversos tipos de mecanismos de atribuição e seus comportamentos. Ao assumir a atividade, o usuário pertencente ao Grupo “Comitê de Análise” e terá acesso ao formulário preenchido com as informações da proposta. Ele poderá alterar as informações conforme julgar necessário, e quando concluir, deverá aprovar ou negar a proposta para então enviar. Ao enviar, o fluxo do processo será direcionado para a próxima atividade, Parecer Supervisor de Crédito. Esta atividade possui um mecanismo de atribuição definido por Papel. Quando um usuário que possui o papel de Supervisor de Crédito assumir a atividade, será exibido a ele o formulário da mesma forma como apresentado na atividade anterior e, igualmente, lhe será permitido alterar os dados da proposta a critério. Ao enviar, o fluxo será direcionado para a próxima atividade, Parecer Gerente Crédito. Esta atividade é idêntica à anterior, com a diferença que o usuário que for assumir deverá ter papel de Gerente de Crédito. A próxima atividade no fluxo depende de uma tomada de decisão. Esta decisão está baseada nos tipos de produtos que a proposta de limite de crédito possui. Se a proposta possuir um Finame, o fluxo será direcionado para a atividade Parecer Comitê Gestor. Caso possua Garantia, será direcionado para Parecer Comitê CEO. Caso a proposta não possua nenhum dos dois produtos citados anteriormente o processo será finalizado diretamente. Se possuir Garantia ou Finame, ao fim de ambas atividades o processo será finalizado e a proposta de limite de crédito estará disponível no GRisco, conforme decisão dos usuários, seja aprovada ou negada.
...
As atividades do processo precisam ser atribuídas para que algum usuário qualificado possa assumir a atividade e dar andamento no processo. Ao assumir a responsabilidade o usuário deverá aprovar ou negar a tarefa. No Fluig, existem várias maneiras de se definir mecanismos de atribuição de atividades. Veja , veja na tabela abaixo os mecanismos disponíveis. No contexto do motor de crédito do GRisco, será utilizado serão utilizados apenas os mecanismos de atribuição Para um Grupo (Pool) e Para um Papel (Pool).
...
Widgets de Consulta Rápida: Diretriz para o Roadmap V12- projeto conjunto VPT - Framework + VP Fluig WCM para prover um framework de desenvolvimento de widgets de consulta rápida.
Como era o Fluig
O fluig de antigamente, antes das experiências de uso, sofria diversas dores, por não ser uma ferramenta totalmente integrada com o sistema. Navegação por múltiplos sistemas, ícones e atalhos, o que complica a centralização das atividades, gestão de segurança não integrada, diversos engines do workflow, difícil usabilidade, tornou o fluig alvo de reclamações.
Entendendo a Experiência #2
A experiência de uso sugere a integração do Sistema de Gestão de Rísco de Crédito (GRISCO) com o Sistema Fluig ECM, com a finalidade de automatizar o processo de aprovação de proposta no módulo Gestão de Risco. Utilizando o engine de Workflow/BPM do Fluig, os Analistas de Negócio terão mais autonomia para configurar o workflow da esteira de crédito do GRISCO conforme as necessidades funcionais de cada cliente. O Sistema GRISCO continua sendo o provedor do serviço de manutenção dos dados da proposta, enquanto o Fluig o gestor e motor de execução do processo de concessão de limite, que será executado e modelado através do Fluig. O módulo GRISCO possui um engine nativo como motor de workflow do fluxo de aprovação de propostas que será substituido pelo Fluig workflow/BPM, integrando com o social. Podemos ver na figura abaixo a representação do processo do GRISCO pelo Fluig Diagrama. O BPM busca através de um formulário informações do GRisco, que é usado como repositório para o fluig.
O processo define os grupo e eventos do processo. Um grupo de evento no GRISCO representa um agrupador de atividades, podemos associar um grupo de evento com um subprocesso.
Abaixo a descrição do processo ilustrado na figura para um melhor entendimento da integração com o GRisco.
...
1
...
Solicitar Proposta Limite
O usuário acessa o Fluig e inicializa um processo de Concessão de Limite de Crédito.
...
2
Registrar Proposta
...
Obs: Neste ponto é necessário implementar uma validação no evento de finalização da atividade para verificar se o usuário realmente cadastrou a proposta no Sistema de Risco.
...
3
...
Executar Motor de Crédito
Esta atividade faz uma requisição ao Motor de Crédito, o retorno do Motor de Crédito é avaliado em uma expressão automatica para determinar o caminho do processo. O retorno do motor é exatamente como ocorre atualmente entre GRISCO e Motor de Crédito (Intellector). O Motor de Crédito retorna uma sigla que define quais os grupos de eventos que serão gerados para a proposta.
...
4
...
Registrar Pendência de Empréstimo
Subprocesso que definie quais serão as atividades de interação humana. Estas atividades são representadas por eventos no GRISCO e estes eventos serão desativados enquanto estiver em interação com o Fluig.
...
5
...
Registrar Pendência de GRAVAME
Nesta atividade o usuário apenas registra a obersão e avança o processo. Em todas as atividades do processo o usuário poderá modificar as informações da proposta acessando o Sistema GRISCO por dentro do Fluig. O formulário do processo irá exibir os dados da proposta em todas as atividades, através da tela do Sistema de Risco.
...
6
...
Esta atividade tem por finalidade consumir o serviço do Sistema de Risco para finalizar o ciclo de vida da proposta, o propósito é notificar o GRISCO do resultado do Workflow de concessão de limite. O resultado é obtido conforme o caminho lógico percorrido pelo Fluig.
Integração com o Social do Fluig
A integração da experiência de uso #2 com o Social do Fluig acontece justamente a cada atividade ou solicitações durante o processo no Workflow, onde entra o alerta na Central de Notificações do Fluig. A central de notificações reúne em um único local do Sistema todos os alertas de atividades e eventos em andamento que foram enviados ao usuário.
Estrutura Workflow Fluig
Na versão 11, iniciamos a externalização dos fluxos de aprovação dos ERPs para o engine workflow/BPM do Fluig que possui aplicativo móvel como sua interface para suportar as aprovações. Cada atividade no Workflow corresponde a uma etapa de aprovação e a próxima etapa só poderá ser alcançada se a anterior tiver sido aprovada. O processo possui tomadas de decisão, ou seja, toma caminhos diferentes conforme os produtos selecionados para concessão do limite de crédito. Se a proposta de crédito tiver os dois produtos Garantia e Finame, significa que serão criadas duas linhas de fluxo, caracterizando um processamento paralelo. Se na atividade uma das linhas for negada pelo usuário, a solicitação será cancelada, mesmo que na outra linha a atividade seja aprovada, e o processo não atingirá seu final.
Assim que alguma decisão onde o usuário está relacionado é tomada, o mesmo recebe um alerta conforme a imagem abaixo.
Resultado da Experiência #2
Obtivemos resultados positivos referente a experiência #2, conseguindo integrar o sistema e torná-lo parametrizável para outras experiências. Com a integração das funcionalidades dos produtos da TOTVS, o Workflow do Fluig efetua a troca de informações com o sistema GRisco, podendo ser utilizado de maneira ágil e conectada. Para que o sistema rodasse livremente, foi preciso ajustar algumas configurações de uso do GRisco, onde basicamente através dos formulários o Fluig busca as informações no sistema.
Tecnologia Utilizada para Desenvolver
Para o desenvolvimento das experiências foi utilizado o framework AngularJS.
O exemplo acima ilustra cerca de 2 diretivas que são utilizadas para dados vinculação no AngularJS.
Imagem acima de um formulário HTML, onde o Angular transforma os objetos .json para html, fazendo o binding.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas