Veja como é fácil desenhar sua política de crédito com Decision Designer

por Bruno Silva (bruno.silva@www.neurotech.com.br)

Quando uma instituição financeira trabalha com concessão de crédito, é natural que ao fornecer crédito para alguém, ela siga algumas regras para determinar os riscos, a capacidade de pagamento do cliente, entre outros aspectos. A estas regras, é dado o nome de  política de crédito. Essa política tem como objetivo orientar as decisões de concessão de crédito de forma consistente e prudente, buscando minimizar riscos e maximizar a rentabilidade. Além disso, ela envolve a análise de informações sobre a situação financeira, histórico de crédito, capacidade de pagamento e outras características relevantes do cliente.

A Neurotech, através da plataforma Riskpack, possui soluções completas para todo o ciclo de vida do crédito, desde a prospecção de clientes até a recuperação de clientes devedores com maior propensão a pagar suas dívidas, descoberta de potenciais fraudes, entre outros. Cada componente do Riskpack cumpre um papel importante neste ciclo, e neste estudo de caso focaremos no Decision Designer.

O Decision Designer é uma ferramenta low-code de desenho de fluxos de trabalho baseada em BPM (business process model). A ideia por trás deste tipo de ferramenta é que usuários de negócio, que normalmente não possuem um entendimento mais aprofundado dos conceitos de programação, consigam expressar suas ideias e regras de negócio através de pouquíssimo código, para isto se utilizando de abstrações, tais como:

• Tarefas e subtarefas (“execute a subtarefa FLX_SCORE”)
• Decisões baseadas em valores (“se o resultado da tarefa FLX_RECEITA_PJ for igual a APROVADO, siga por este caminho, senão, continue por aquele outro caminho”)
• Resultados (“Ao chegar no final deste caminho, informe que esta tarefa terá como resultado o valor REPROVADO”)

Para o contexto do Decision Designer, as tarefas podem ser dos seguintes tipos:

• Fluxo: são aquelas tarefas que contém desenhos intuitivos que indicam o “caminho” pelo qual a decisão vai seguir;
• Tabela: são tabelas de decisão, no padrão de “se isto e aquilo, então o resultado será este”. Representam uma outra forma de tomar decisão, mais textual e um pouco mais avançada, mas quem também não envolve programação;
• Variável: são valores básicos que podem ser comparados e atribuídos durante a tomada de decisão; estes valores podem ser do tipo número inteiro ou real, texto, lista ou booleano (utilizado para valores sim e não)
• Recurso externo: são integrações com outros módulos do Riskpack, como uma consulta a algum bureau externo, através do Gateway, ou uma consulta a uma base de dados através do Upload, entre outras possibilidades

Uma importante consequência da definição da tarefa poder se dividir em subtarefas é que podemos estruturar as ideias lógicas de maneira hierárquica, onde um usuário com mais entendimento de negócio pode desenhar os fluxos de um modo mais alto nível, indicando, por exemplo, os passos em linhas gerais e os caminhos pelos quais a decisão deve percorrer, enquanto um usuário mais técnico pode, por exemplo, detalhar melhor e dividir os fluxos em regras, e aplicar tabelas, variáveis e até mesmo consultar recursos externos para enriquecer a tomada de decisão.

Além disso, criar regras de maneira hierárquica também permite sua adição à base de reuso, sendo possível utilizá-las sempre que necessário em novas políticas, tornando o processo bem mais produtivo e documentado, uma vez que as regras que foram adicionadas à base do reuso já foram extensivamente testadas e aplicadas anteriormente.

Estudo de caso

Para exemplificar melhor como podemos otimizar a divisão de papéis durante a construção de uma política, imagine o seguinte cenário: 

O dono de uma loja de conveniência de um pequeno posto de gasolina de beira de estrada (vamos chamá-lo de Seu André) decide fazer um cartão de fidelidade para cativar os viajantes que por ali passam. A sua ideia inicial é, baseado nos dados fornecidos pelos clientes, ou aplicar algum tipo de desconto progressivo para clientes rotineiros ou fornecer o cartão fidelidade para novos clientes. Como Seu André ama muito sua cidade, e sempre que pode, faz propaganda do turismo local, se os clientes novos vierem de outros estados ele também gostaria adicionalmente de entregar-lhes algum pequeno souvenir (um chaveiro, ou um porta-moedas, entre outros). Além do mais, clientes que fazem aniversário naquele dia recebem um cartão de parabéns personalizado e uma taça de champanhe para fazer um brinde.

Este simples cenário é riquíssimo para exemplificar vários elementos do Decision Designer, associados aos conceitos de programação. Por exemplo, podemos começar a pensar de forma muito alto nível os tipos de clientes que pensamos em atender, quais são as variáveis de entrada que iremos precisar, etc. Num cenário do mundo real, precisaríamos de muitas informações para conferir realmente se o cliente possui aqueles dados que foram fornecidos, qual sua renda, se existe alguma tentativa de fraude, entre outras coisas. Vamos então considerar apenas o que está definido no exemplo para modelar a política de acordo:

• Nome: Para personalizar o cartão de aniversário
• Data de nascimento: Para saber se hoje é seu aniversário e também verificar se você é maior de idade para receber a taça de champanhe
• CEP: Para verificar se o cliente é deste ou de outro estado
• Quantidade de compras no estabelecimento: Para saber se é cliente novo ou não, e também para calcular o desconto progressivo

Por definição de padrão, todas as variáveis de entrada no DD começam por PROP_, derivado de propostas Então, para as variáveis acima, podemos criar as seguintes propriedades:

Uma vez que foram definidas as variáveis que serão utilizadas na política, o próximo passo é traduzir os cenários descritos em regras do tipo SE -> SENÃO -> ENTÃO. O Decision Designer é próprio para isto, e sua interface intuitiva ajuda bastante nesta tarefa. Considerando inclusive que Seu André não possui um conhecimento aprofundado sobre programação, ele pode desenhar a regra principal sem grandes dificuldades, da seguinte forma:

Que interessante! Seu André conseguiu, no formato de fluxo de decisão, descrever exatamente o que ele espera como saída da sua política. A forma como a regra foi dividida em sub-regras é uma variação de um conceito de programação chamado de divisão e conquista, onde você divide um problema em partes menores para facilitar seu entendimento e conseguir resolver de maneira direta um problema muito simples, fazendo a junção dos resultados para compor o resultado final.

Como é possível ser observado, a regra principal foi dividida em quatro sub-regras:

• RGR_CLIENTE_NOVO: que indica se um cliente é novo (NOVO) ou já cliente (RECORRENTE)
• RGR_ESTADO: define se um cliente é deste estado (MESMO) ou de outro estado (OUTRO)
• RGR_ANIVERSARIO: verifica se hoje é aniversário do cliente (SIM ou NÃO)
• RGR_IDADE: decide se o cliente pode ou não receber o brinde alcoólico através de sua idade.

Ele ficou tão feliz em ter conseguido desenhar a regra principal de maneira tão fácil, que se aventurou também a definir as sub-regras. Começando pela regra de definição se é um cliente recorrente ou novo (RGR_CLIENTE_NOVO), ele notou que bastava comparar o número de compras daquele cliente (que já recebe como entrada), para decidir se o cliente é novo ou recorrente.

Para definir a RGR_IDADE, apesar de não saber programar, ele notou que no Decision Designer existe uma seção com funções pré-definidas, e uma delas é justamente calcular idade. Que legal! Para utilizar a função calcularIdade, ele arrastou diretamente no desenho e percebeu que a função pedia qual a variável de entrada e qual a variável de retorno. Como ainda não tinha criado a variável de retorno, ele criou uma nova variável do tipo CALC para isto. As variáveis CALC possuem este nome porque, por definição de padrão, são calculadas em tempo de execução, em comparação às variáveis PROP que vêm como entradas da proposta, como já vimos anteriormente.

Neste caso, ele criou a variável CALC_IDADE para, a partir da função calcularIdade, e recebendo a PROP_DATA_NASCIMENTO como entrada, saber quantos anos o cliente tem, conforme a imagem a seguir:

Seu André agora se deparou com dois cenários que não soube resolver sem a ajuda de códigos de programação:

1. Como saber o estado de um cliente, apenas com o CEP em mãos?
2. Como saber a data de hoje, para comparar com a data de nascimento e saber se é aniversário do cliente ou não?

Seu André esperava, com a resposta destas perguntas, concluir as regras RGR_ESTADO e RGR_ANIVERSARIO, respectivamente. A boa notícia é que, para a primeira delas, ele vai conseguir resolver no DD sem utilizar quase nenhuma programação! Para isto, ele vai utilizar um recurso muito interessante do DD que é a integração com sistemas externos, para enriquecer sua tomada de decisão.

Ao navegar pelo DD com suas credenciais do Gateway, ele notou que a consulta Correios tem as seguintes entradas e saídas:

É exatamente o que ele queria! Com um CEP como entrada, obter qual o estado (ou UF) daquele CEP. Da mesma forma que ele conseguiu arrastar elementos para a regra principal, ele poderá arrastar a consulta Gateway para a sua área de desenho. Antes disso, será necessário indicar que a variável que ele escolheu como entrada para o CEP (PROP_CEP) seja vinculada à entrada cep da consulta CORREIOS:

Seu André notou que a saída do Gateway para saber o estado de um CEP é a saída UF, mas que ela é do tipo texto. Variáveis do tipo texto não podem ser arrastadas diretamente para a área de desenho. Ele então, teve uma ideia: que tal criar uma variável calculada com a lista dos estados, e aí sim, poder arrastá-la para tomar a decisão? Isto é totalmente possível, mas fazemos aqui uma reflexão com o Seu André: apesar da lista de estados ser relativamente pequena, e se fosse uma lista de países por exemplo? Ou dos municípios brasileiros? Como iríamos preencher centenas ou até milhares de valores na lista?

A resposta é simples: como nossa decisão para a RGR_ESTADO é baseada no fato de ser deste ou outro estado, a lista não precisa ser exaustiva! Neste caso, podemos fazer uso do atributo Default, que indica qual o valor padrão daquela lista. Este valor é útil porque ao tentar atribuir qualquer outro valor não presente na lista, ele será aplicado. Desta forma, a lista CALC_ESTADO ficou da seguinte forma:

Com a lista criada, Seu André vinculou a saída uf da consulta CORREIOS ao CALC_ESTADO:

Uma vez que foram vinculadas entradas e saídas para uma consulta do Gateway, agora sim é possível incluí-la no desenho e tomar decisões baseadas tanto no resultado em si, quanto nas variáveis que foram vinculadas. Deste modo, a regra RGR_ESTADO, fica assim:

Ou seja, a consulta CORREIOS do Gateway é acionada, recebendo como entrada o cep, que foi copiado de PROP_CEP, e dentre as suas saídas, copia o resultado da saída uf para a variável CALC_ESTADO, e caso o resultado do Gateway indique qualquer outro estado, a lista irá receber o valor OUTROS através do atributo Default, resultando na saída OUTRO da RGR_ESTADO.

Agora o Seu André está num impasse: chegou na última das regras, a RGR_ANIVERSARIO. Já familiarizado com os conceitos que já vimos até agora no DD, ele não se recorda de nenhum recurso que consiga ajudá-lo diretamente. Mas como ele é sempre muito antenado, está sabendo que só se fala em LLMs e ajudantes de chat em IA, tipo o ChatGPT (como eu disse, ele é muuuuito antenado). 

Esta é uma excelente oportunidade para pedir ajuda ao ChatGPT, mas antes, como ele mesmo já desconfia, talvez seja uma boa ideia criar uma variável calculada CALC_ANIVERSARIO, para decidir na sua área de código (ícone ?) se é ou não seu aniversário. Como a lista por padrão já é criada com os valores SIM e NÃO, não será necessário nem alterar a lista de valores.

E agora, com ajuda do ChatGPT, Seu André pode inicialmente ficar um pouco confuso, e dizer: “quero saber se hoje é aniversário”, e vai notar que a resposta pode ser um pouco abrangente demais. A ideia é que ele seja o mais específico possível na hora de solicitar. Vamos dar uma ajudinha! Esta seria uma boa consulta a fazer:

Preciso de um código em Java que, dada a variável de texto aniversario (que é uma data no formato dia/mês/ano), altere o valor de um objeto para SIM ou para NÃO. Aplique as seguintes restrições:

• Não utilize nenhum import no código, apenas o nome completo das classes
• Não apresente o bloco de código completo, apenas o trecho correspondente
• A primeira linha deste bloco deve ser a inicialização da variável aniversario no seguinte formato: String aniversario = (String) Global.PROP_DATA_NASCIMENTO.run();
• A última linha deste bloco deverá ser a atribuição de valores baseado no resultado: se verdadeiro: setValue(“SIM”), caso contrário, setValue(“NÃO”)

Existem várias formas de chegar ao mesmo resultado e o código gerado poderá ser levemente diferente, mas a ideia geral está bem descrita e há grande chance de sucesso. Sobre as restrições, as duas primeiras são especificidades do DD, e não têm relação direta com o problema (resumindo, é muito provável que elas apareçam em todas as consultas que sejam feitas ao ChatGPT para o DD), e as duas últimas são para vincular as entradas e saídas que desejamos (variável PROP_DATA_NASCIMENTO e alterar o valor do próprio CALC_ANIVERSARIO, respectivamente).

Concluindo esta etapa, Seu André colou seu código e ficou muito contente, pois agora, finalmente sua política está quase construída e só precisamos dar-lhe uma pequena ajudinha, certamente nas próximas ele já conseguirá desenhá-la completamente sozinho! Para concluir a política, ele arrastou a CALC_ANIVERSARIO para a RGR_ANIVERSARIO e terminou o seu desenho:

Com isto, conclui-se a saga do Seu André para o desenho de sua política. De sua rápida jornada, podemos extrair algumas coisas interessantes:

• O processo de tomada de decisão pode aproveitar-se de estratégias de divisão de problemas em problemas menores
• O Decision Designer é ótimo com abstrações, favorecendo bastante usuários leigos em programação, mas também fornece possibilidades para escrita de códigos para usuários mais avançados
• Ferramentas de IA assistivas são muito poderosas, mas podem receber informações demais sobre nosso negócio caso não tenhamos cuidado. Neste exemplo do Seu André, ele acertou bastante ao pedir apenas uma parte específica do seu problema para ser resolvido (cálculo de aniversário). Imagine se ao invés disso, por exemplo, ele descrevesse todo o funcionamento de sua política e seu concorrente, o Seu Eduardo, começasse a também fazer perguntas semelhantes para a IA e se aproveitasse disso?. Seu André acabaria, sem saber, ajudando a inteligência artificial a melhorar suas respostas sobre pontos muito peculiares do seu negócio e poderia, potencialmente, expor alguma estratégia.

Este estudo, apesar de seu caráter fictício, cobriu a maior parte dos elementos que podem ser utilizados para a criação de uma política. E se Seu André, que não sabe nada de programação conseguiu fazer um exemplo assim, você com certeza vai fazer políticas muito mais complexas com o uso do Decision Designer. Faça como ele e comece a utilizar o Decision Designer para criar suas próprias políticas de crédito com pouquíssimo uso de código.

Acesse: https://www.neurotech.com.br/desafios/