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 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 está 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 e 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, lhe será exibido a ele o formulário da mesma forma como foi exibido apresentado na atividade anterior e, igualmente, lhe será permitido alterar os dados da proposta a critério. Ao enviar a atividade, 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 a 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. Caso possua 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).
...
Para permitir a integração com o Fluig, foi necessário expor uma série de serviços do GRisco. Para tanto, foi criado criada uma camada de serviços utilizando tecnologia REST bem como SOAP. Veja na tabela abaixo os serviços expostos:
...
Serviços | Método | Descrição |
|---|---|---|
DomainsResource | listarResponsabilidade | Retorna um Array de Responsabilidades conforme domínio de responsabilidades do Credimaster (DominioResponsabilidadeCredimaster). |
DomainsResource | listarDominioResponsabilidadeLimiteCredito | Retorna um Array de Responsabilidades conforme domínio de responsabilidades de limite de crédito (DominioResponsabilidadeCredimaster). |
DomainsResource | listarTipoPessoa | Retorna um Array de Tipo de Pessoa conforme domínio de tipo de pessoas no GRisco (DominioTipoPessoa). |
GRiscoAbrangenciaResource | buscarDataProcessamento | Busca data do último processamento, utilizada para determinar se as Certidões estão vencidas ou não. |
GrupoBemResource | listarGrupoBem | Retorna uma lista dos Grupos de Bens cadastrados no GRisco. |
GrupoBemResource | listarTipoBem | Retorna uma listra lista dos Tipos de Bens de um determinado grupo. |
PropostaCreditoResource | executaPropostaCredito | Executa a criação inicial do objeto que representa a Proposta de Limite de Crédito com as informações mínimas, inclusive dados de configuração do GRisco, retornando o DTO com o qual será iniciado o processo de elaboração da Proposta no Fluig. |
PropostaCreditoResource | listarProdutos | Busca os produtos disponíveis cadastrados de acordo com o tipo de operação. |
PropostaCreditoResource | confirmarPropostaLimite | Efetua a primeira persistência da Proposta de Limite de Crédito, a partir deste método a proposta passa a existir com um código de operação. |
PropostaCreditoResource | gravarPropostaLimite | Grava as alterações efetuadas numa proposta já criada anteriormente. |
PropostaCreditoResource | listaPessoaLimiteCredito | Retorna lista de Clientes conforme parâmetros de pesquisa. |
PropostaCreditoResource | buscaPropostaLimiteCredito | Retorna uma proposta de limite persistida no GRisco. |
SegurancaResource | buscarListaEmpresaAutorizada | Busca empresas para listagem e definição da abrangência. |
SegurancaResource | buscarListaUnidadeAutorizada | Busca unidades de determinada empresa para definição da abrangência. |
...
Serviços | Método | Descrição |
|---|---|---|
PropostaLimiteCreditoService | gravarPropostaLimiteAprovada | Grava proposta de limite já persistida com situação de Aprovada. |
PropostaLimiteCreditoService | gravarPropostaLimiteNegada | Grava proposta de limite já persistida com situação de Negada. |
Widgets
Partindo do princípio que estamos na tela inicial do Fluig podemos considerar um dos principais componentes de tela, que oferece a visualização de funcionalidades específicas na página Home. Os widgets servem para o acompanhamento de Tarefas, Processos ou Documentos, onde de forma rápida obtemos a visualização das atividades. Cada widget é exibido na Home do portal ou em páginas cadastradas, podendo ser organizadas conforme o usuário desejar. Fruto da experiência de uso #4, widgets de gestão e experiência #5 os widgets de consulta rápida, provoca os usuários para uma atitude tática e operacional em frente aos processos que operam, com um acesso rápido a conteúdo dos sistemas.
Widgets de Gestão: Diretriz para o Roadmap V12- projeto conjunto VP Segmentos e VP Fluig WCM para prover a integração do WCM com o GoodData e TOTVS BA Cognos, desenvolver KPIs e Dashboards para os 10 segmentos TOTVS.
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.
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. 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