Pontos confusos - Eventos e Atividades

Oi Gabriel, tudo bem?

Obrigada pelo seu feedback.

Vou encaminhá-lo para nosso instrutor.

Bons estudos.

Caro Gabriel,

Obrigado pela postagem!

Podemos dividir sua dúvida em 2 temas centrais:

1- Entender por que usamos eventos com verbos, embora o BPMN Guide oriente a usar substantivos.

2- Explicar nos 4 exemplos que você citou extraídos do curso, o porquê não usamos fizemos a representação por eventos ao invés de atividades.

Então vamos lá..

1- Conforme você deve ter lido em outras respostas do fórum deste curso, procuramos dar uma "pegada" prática neste curso, neste sentido pela nossa experiência do que observamos a vários anos atuando no mercado de modelagem de processos, não é raro de encontrarmos eventos representados como verbos, e o principal não é "errado" também.

Note que no processo modelado no curso temos um evento "Item indisponível para análise" que não está de maneira proposital usando o verbo, para fazer o aluno refletir que é aceitável o uso de verbos e substantivos para representarmos eventos.

Novamente, um dos propósitos do curso é ajudar ao aluno a ter uma visão prática de como o BPMN é encontrado no mercado, que eu alguns casos como esse não é ao "pé da letra" do BPMN Guide.

2- Agora vamos as explicações dos 4 bullets de eventos:

• Categorizar o Cliente: Do jeito que você sugeriu de criar atividade de script automático, além de desdobrar o processo em atividades e tempo de dedicação e consumo de recursos humanos ou sistêmicos necessariamente, geraríamos custos e tempos adicionais na execução e principalmente quebraríamos um requisito mapeado para o processo que seria de em alguns casos mantermos o processo de venda tradicional, ou seja, não categorizarmos o cliente, e aí neste caso simplesmente o evento "Categorizar Cliente" não ocorre.

• Avaliar possibilidade de vendas agregadas: Um dos requisitos que observamos junto a Gerente da Livraria do Conhecimento é que em alguns casos assim que o cliente "Realizar o Pedido" enquanto a disponibilidade do mesmo está sendo feita em estoque e o vendedor está envolvido em pegar os dados para cadastro do cliente, em função do conteúdo do pedido poderíamos ter um evento de avaliação da possibilidade de propor vendas agregadas, considerando um relacionamento pré-configurado de venda de itens associados, algo como vemos por exemplo em sites, clientes que compraram isso, também compraram isso...Neste caso, como já deixaremos a consulta a este relacionamento de venda de itens no BD este evento teria como finalidade neste momento deixar o vendedor apto e propor um novo item ao cliente sem precisar recorrer a sua memória do que item seria semelhante.

• Confirmar prazo de entrega: Na linha prática apresentada no curso, muitas vendas podem se perder mesmo tendo o produto em estoque devido ao cliente não concordar com o prazo de entrega ou ficar esperando o vendedor atuar no processo para informar algum prazo por "longos" minutos para depois vir com aquela "pérola" o sistema está lento ou sem comunicação...Assim, não precisamos criar uma atividade no processo para fazer algo que um evento de maneira automática inclusive preservando o tempo de atendimento ao cliente pelo gatilho de tempo faria, na sequência ao resultado da consulta ao estoque.

• Avaliar itens e Avaliar prazos de disponibilidades: Não existe redundância, senão vejamos ainda no processo expandir vendas rodamos o evento "Avaliar Possibilidade de Vendas Agregadas" que "chama" o sub-processo Vendas Agregadas, a partir da entrada no sub-processo ocorre uma consulta a "1 ou n" itens relacionados ao contido no pedido inicial. Neste caso, esta consulta "Consultar Disponibilidade do item" é representada por atividade para garantirmos que o vendedor fará novo estimulo em função do andamento da venda ao sistema. Com isso, ao realizar este estímulo a avaliação de detalhes complementares do item (precisamos munir o vendedor de informações para o processo de venda) e a avaliação de prazos quanto a disponibilidade do item para que o vendedor via eventos, para que o vendedor possa passar os detalhes ao cliente sobre a venda agregada com precisão e exatidão!

Esperamos poder ter esclarecido os pontos ressaltando que as respostas foram em função da pegada prática do curso e dos requisitos ilustrativos usados no case de modelagem do processo para a Livraria aplicado no curso!

Parabéns pela sua dedicação aos estudos no tema!

Olá Fernando,

Agradeço a resposta bastante completa.

Sobre o ponto 1, realmente não existe nada errado em utilizar verbo e entendi o ponto de vista, mas creio que você entendeu também porque vários alunos ficaram com dúvidas nesse ponto.

Sobre o ponto 2:

• Categorizar cliente: concordo que a minha sugestão é mais custosa. Contudo, no evento mapeado não fica claro (ao menos para mim) quem vai classificar, e nem como o evento chegará ali, pois ele não está vindo da atividade anterior, pelo que você explicou. Sobre o requisito de termos o processo de venda tradicional, da maneira como ficou o processo TO BE, não enxergo como ele poderia ocorrer. O gateway paralelo de junção ficaria esperando a execução dos três branches entrantes. Logo, se o evento não ocorrer, a execução não segue. Correto?
• Avaliar possibilidade de vendas agregadas: o caso de uso de venda agregada é claro e bem explicado, só que para esse evento, na minha opinião, não fica claro o que ou quem o geraria. Eu havia entendido que seria a atividade de realizar pedido de clientes, e por isso sugeri de o evento ser "pedido gerado".
• Confirmar prazo de entrega: a explicação que você deu acima difere daquela do curso (pelo que me lembro). Mas mesmo assim, ainda não entendi o emprego do evento tipo timer nesse caso.
• Sobre os eventos do sub-processo, parece-me que você intende que os eventos enviem mensagens ao vendedor, mas esse sub-processo está em paralelo com o cadastro do cliente no processo principal. E não vejo o tratamento desses eventos no processo principal. Por isso que o mapeamento do caso de uso pro diagrama desenhado ficou, a meu ver, confuso.

De qualquer forma, agradeço as explicações. Recomendaria, talvez, que clarifiquem alguns pontos no diagrama do projeto.

Gabriel, tuas duvidas em relação a eventos foram as minhas tbm, durante o curso. é um pouco oneroso pro diagrama mas acho que vale a pena fazer a atividade antes ou depois deste evento que representa o estado que se encontra. Como no exemplo que tu deu de "pedido gerado", carrega um estado, em que o evento condiciona um momento do processo. Assim os eventos de Timers como questionou podem ser usados com clareza, tipo..

Uma semana (evento timer) > Registrar pedido de venda (atividade) > Pedido de venda registrado (evento Sinal enviado)

Algo assim

Falo destes detalhes pois trabalho com governança de muitos processos e estes eventos determinam a comunicação entre os processos.

Exato Lucas.

O exemplo que você deu deixa claro o significado do evento timer, e o evento intermediário que mencionei.

Obrigado.

Caros Gabriel e Lucas,

Obrigado pelas postagens e interações. Sem dúvida estas discussões enriquecem bastante as reflexões e estudos no tema abertos no curso.

Queria apenas reforçar alguns conceitos ilustrados na prática, por meio do processo de "Expandir Vendas" oriundas na notação BPMN, que são:

• Evento Intermediário de Timer: O qual foi inserido no diagrama para representar todas as vezes que tivermos uma consulta em estoque, onde dispararmos um gatilho sem intervenção humana, para se o item tiver disponibilidade ele já informar qual seria o prazo de entrega, afinal como vimos nos requisitos do curso não estamos fazendo apenas uma consulta a uma base de dados representando um estoque "fisicamente" contido na Livraria. Assim , reforçamos que não precisamos de atividade nesta etapa do processo. Sobre a relevância dos estados indicados, concordamos de que isto precisa ser tratado, muito embora neste nível conceitual esta discussão de detalhe do processo ainda não seja requerida. Mesmo assim, podemos considerar que o estado do pedido terá uma transição na saída do gateway paralelo (+) quando o pedido por finalizado, desta forma, não precisaríamos criar uma atividade para representar "apenas" uma transição de estado, neste caso!

• Gateway Paralelo (+): No caso do processo mapeado serve para indicar os 3 caminhos para serem abertos quando a atividade "Realizar o Pedido de Vendas" for executada, que são: 1- Venda Tradicional - consulta ao estoque e informe automático do prazo de entrega 2- Cadastrar o Cliente - No sentido de registrar detalhes do relacionamento e abrir a possibilidade da Loja traçar uma estratégia de venda em cima do perfil dele (via promoções customizadas). 3- Vendas Agregadas - No sentido de propor algo rápido com itens adicionais de venda associados diretamente ao item que o cliente solicitou no pedido inicial.

Assim, a função deste elemento gateway paralelo é só garantir a possibilidade a partir da atividade "Realizar o pedido" que estes 3 requisitos de atendimento - venda sejam cumpridos, mesmo que um deles traga um resultado "null" na saída do gateway paralelo (que representa o tratamento- recebimento das respostas dos 3 caminhos incluíndo o sub-processo) e antes de ir para a atividade "Finalizar Pedido". Logo mesmo que um evento gere uma resposta nula o processo segue em execução.

De fato, o tema de modelagem de processos de maneira alguma será exaurido em apenas um curso, por isso mesmo estamos em processo de produção de outros cursos no tema para gradativamente irmos complementando o conteúdo apresentado neste curso que foi pioneiro no tema dentro da plataforma da Alura e com isso, termos outros debates que nem esse focados neste tema onde estudaremos outros processos, modelagens e representações com a visão prática dos elementos de BPMN!

Bons estudos!