Histórico da Página

trueCenário
Em um processo de Abertura de ouvidoria, quando um cliente abre uma reclamação, ele precisa informar qual é a categoria do seu problema, se é qualidade do produto, entrega do produto ou problemas no atendimento. Com base nisso, depois da análise prévia da ouvidoria e o envio de um parecer para o cliente, a reclamação é encaminhada para a área responsável pela sua resolução, de acordo com a categoria do problema.

trueCondição 1
trueBlueRegra 1
→ Campo do formulário Categoria da reclamação precisa conter um dado igual a Campo valor qualidade.

trueCondição 2
trueBlueRegra 1
→ Campo do formulário Categoria da reclamação precisa conter um dado igual a Campo valor entrega.

trueCondição 3
trueBlueRegra 1
→ Campo do formulário Categoria da reclamação precisa conter um dado igual a Campo valor atendimento.

Significa que, quando a reclamação chegar no componente Exclusivo, será analisada a categoria do problema do cliente e, a partir disso, encaminhará a reclamação será encaminhada para o fluxo correspondente à área responsável pela sua resolução do problema.

Vamos supor que o cliente selecionou Entrega como a categoria do problema no formulário da reclamação. Nesse caso, a Condição 2 é atendida e a reclamação é encaminhada para a área de logísticaLogística, que precisa analisar o ocorrido e enviar uma solução para o cliente.

trueCenário
Em um processo de Aprovação de compra, é necessário que a aprovação seja feita pelo responsável pela alçada de acordo com o valor da compra. Ou seja, se for uma compra de até R$ 5.000,00, o próprio gestor pode aprovar. Se for entre R$ 5.001,00 e R$ 10.000,00, precisar ser aprovado pelo diretor. E, acima de R$ 10.000,00, é necessário que o diretor da área aprove.

trueCondição 1
trueBlueRegra 1
→ Campo do formulário Valor da compra precisa conter um dado menor ou igual a Campo valor 5000.

trueCondição 2
trueBlueRegra 1
→ Campo do formulário Valor da compra precisa conter um dado maior que Campo valor 5000.
E
trueBlueRegra 2
→ Campo do formulário Valor da compra precisa conter um dado menor ou igual a Campo valor 10000.

trueCondição 3
trueBlueRegra 1
→ Campo do formulário Valor da compra precisa conter um dado maior que Campo valor 10000.

Significa que, quando a solicitação chegar no componente Exclusivo, será avaliado o valor da compra e será verificada qual condição é atendida com base nesse valor, encaminhando a solicitação para o aprovador correspondente.

Vamos supor que o valor da compra em questão é R$ 6.500,00. Nesse caso, a Condição 2 é atendida, visto que o valor é maior que R$ 5.000,00 e menor que R$ 10.000,00.

trueCenário
Em um processo de Suporte técnico de uma prestadora de serviço de Internet, quando um cliente abre uma solicitação de suporte, o primeiro nível de atendimento precisa identificar a possível origem do problema, para que ela seja encaminhada para a área correta oferecer uma solução. Sendo assim, na análise do atendente do primeiro nível, é necessário determinar se a causa está relacionada à software, hardware ou conectividade.

trueCondição 1
trueBlueRegra 1
→ Campo do formulário Possível causa precisa conter um dado igual a Campo valor software.

trueCondição 2
trueBlueRegra 1
→ Campo do formulário Possível causa precisa conter um dado igual a Campo valor hardware.

trueCondição 3
trueBlueRegra 1
→ Campo do formulário Possível causa precisa conter um dado igual a Campo valor conectividade.

Significa que, quando a solicitação de suporte chegar no componente Exclusivo, será analisada a possível causa do problema do cliente e, a partir disso, encaminhará a solicitação será encaminhada para o fluxo correspondente à área responsável pela possível causa.

Vamos supor que o atendente analisou o que o cliente reportou e selecionou Conectividade como a possível causa do problema no formulário da solicitação. Nesse caso, a Condição 3 é atendida e a solicitação é encaminhada para a área de manutenção Manutenção de redes, que é a responsável por problemas de conectividade.

Basicamente, a diferença entre esses componentes é:

• Exclusivo: decide o destino da solicitação baseado em condições e a direciona para o fluxo da primeira condição atendida. A partir disso, ela segue adiante em um fluxo único;.

  #ebecf0

  trueExemplo
  Em um processo de Aprovação de crédito, um cliente faz uma solicitação de crédito para um banco e o processo precisa determinar se a solicitação é aprovada ou rejeitada. Para tomar essa decisão, esse componente analisa a pontuação de crédito que o cliente possui no mercado. Se a pontuação for maior que 700, o crédito é concedido e a solicitação segue para as etapas necessárias para que seja liberado ao cliente. Caso contrário, o crédito é negado e a solicitação é finalizada.
  

• Paralelo: divide o fluxo em várias etapas que podem ser executadas em paralelo e, depois de finalizadas, o fluxo se torna único novamente;.

  #ebecf0

  trueExemplo
  Em um processo de Lançamento de produto, as etapas Marketing, Logística e Treinamento de vendas podem ser feitas simultaneamente. Dessa forma, esse componente divide o fluxo em três etapas e indica o início dessas etapas que serão executadas em paralelo. Quando finalizadas, as três etapas são unificadas pelo componente Join e o fluxo volta a ser único.
  

  
  

• Inclusivo: é uma junção do Exclusivo e do Paralelo, ou seja, divide o fluxo no número de etapas correspondente ao número de condições que foram atendidas.

  #ebecf0

  trueExemplo
  Em um processo de Análise de renda, o banco verifica qual é a renda familiar do cliente para que diferentes tipos de crédito ou investimentos sejam aprovados ou oferecidos. Existem 3 condições:

  1. se a renda for maior que R$ 8.000,00, o financiamento de automóvel é liberado para o cliente;
  2. se a renda for maior que R$ 15.000,00, o financiamento de imóvel é liberado para o cliente;
  3. se a renda for maior que R$ 20.000,00, a compra de títulos do governo é oferecida como investimento para o cliente.

  Vamos supor que um cliente possua a renda de R$ 18.000,00. Quando sua renda for analisada, as duas primeiras condições serão atendidas. Neste caso, o fluxo seguirá paralelamente por dois caminhos: o que leva para a etapa Liberar financiamento automóvel e o que leva para a etapa Liberar financiamento imóvel. A terceira condição não é atendida, por isso, o fluxo não seguirá pelo caminho correspondente a ela.

Não. O componente Exclusivopor si só não costuma comprometer o desempenho de um processo de forma significativa. No entanto, o impacto no desempenho depende mais do contexto em que ele é utilizado e das decisões associadas a ele.

Se houver muitas condições complexas sendo avaliadas ou se o processo tiver muitos componentes Exclusivos com decisões complicadas em cada passo, isso pode, de fato, afetar o desempenho de forma indireta, mas não por causa do componente em si, mas pela lógica de decisão ou pela quantidade de verificações validações necessárias.

Além disso, em ambientes que exigem processamento de alta carga ou baixa latência, o número excessivo de verificações validação de condições em componentes Exclusivos pode, em alguns casos, aumentar o tempo de execução do processo. Isso seria mais um reflexo da lógica e da complexidade da aplicação do que do componente em si.

No geral, o componente Exclusivo não costuma ser a causa direta de baixo desempenho, mas a forma como ele é aplicado, em conjunto com outras práticas e a complexidade das condições envolvidas, pode influenciar no tempo de execução do processo.

Sim, é possível criar múltiplas regras para cada condição, bem como, criar múltiplas condições para serem verificadas validadas em cada componente Exclusivo de um processo.

Porém, vale ressaltar que as condições são verificadas validadas na ordem em que são criadas. Por isso, é importante garantir que a lógica de decisão seja clara para evitar que rotas inadequadas sejam seguidas.

Também é importante que exista um fluxo padrão, que funciona como um escape e será seguido quando nenhuma das condições for atendida.

Em resumo, é possível utilizar várias regras e condições, desde que cada rota tenha sua própria expressão condicional. A escolha da rota a ser seguida é feita de forma exclusiva com base na verificação validação dessas condições.

Para testar se as condições criadas para o componente Exclusivo estão corretas, é possível seguir algumas abordagens:

• validação manual: revisar as condições – analisando as expressões e verificando se são lógicas e se não existe sobreposição ou ambiguidades entre elas – e compreender os dados envolvidos – entendendo quais variáveis ou dados são avaliados para garantir que as condições estejam de acordo com o esperado em cada situação;

• testes: criar um conjunto de entradas (valores das variáveis) que abrangem as possibilidades de decisão que o componente pode tomar. Depois, executar o processo com essas entradas e verificar se ele segue a rota correta;

• ferramentas de teste de BPMN: utilizar alguma ferramenta que ofereça recursos específicos para validação e testes do componente Exclusivo. Essas ferramentas permitem simular a execução do processo, analisar os fluxos e verificar se as decisões tomadas pelo componente estão corretas;

• revisão lógica de negócio: contar com a análise colaborativa dos especialistas no negócio pode ajudar a validar se as condições criadas fazem sentido para o objetivo do processo. 

Existem alguns motivos pelos quais uma solicitação pode ficar "presa" no componente Exclusivo e geralmente eles estão associados à forma como as condições e lógicas de decisão foram configuradas. Os motivos mais comuns são:

• condição não atendida: nenhuma das condições configuradas para o componente foi atendida e não existe um fluxo padrão de escape. Isso pode ocorrer quando as condições não foram configuradas corretamente, não consideraram algum cenário mais específico ou a lógica das condições não foi definida de forma adequada;

• dados ou variáveis de entrada ausentes ou inválidos: quando dados ou variáveis que são utilizados para determinar a rota que a solicitação deve seguir não estão presentes no processo ou são inválidas. Por exemplo, um dado ou variável que deveria ter sido preenchida anteriormente e não foi;

• inconsistência de execução: se ocorrer alguma inconsistência ou falha técnica na plataforma que está executando o processo no momento de avaliar as condições do componente, o fluxo pode ser interrompido sem ser direcionado para uma rota válida. Isso também pode ocorrer por questões de timeout – se o fluxo envolve tempos de espera ou tempos máximos e esses tempos tenham sido atingidos sem que existam definições sobre como lidar com esses casos – e por questões de integração – quando o fluxo depende de dados de uma fonte externa (como API, banco de dados ou integração com outros produtos) e ocorrer alguma falha nessa fonte;

• falta de fluxo padrão: não há um fluxo padrão por onde a solicitação possa seguir caso nenhuma das condições seja atendida. É uma boa prática sempre definir um fluxo padrão, pois garante que o fluxo não seja interrompido quando nenhuma condição foi atendida;

• falhas em subprocesso ou etapas anteriores: se antes do componente um subprocesso ou etapa falhou ou não foi completada corretamente – não fornecendo as informações necessárias para a decisão, por exemplo – pode afetar a verificação validação das condições e impedir o avanço da solicitação.

Para resolver essas questões, é importante revisar as regras e condições, garantir que as variáveis de entrada estão sendo corretamente inseridas e sempre definir um fluxo padrão para que sempre haja uma rota válida para a solicitação seguir adiante.