Problemas comuns na modelagem de processos em BPMN II – Uso de eventos de mensagens para comunicação dentro do processo

Continuando a série de artigos que falam de erros, problemas e inconsistências básicas de modelagem (veja artigo já publicado aqui), vamos falar hoje de outra situação bem comum, que é a utilização de eventos de mensagem para comunicação entre papéis/raias dentro de um mesmo processo.

Vamos imaginar um processo ponta a ponta de uma organização, como por exemplo um processo de compras, onde em determinado trecho temos uma comunicação entre dois papéis ou áreas diferentes que atuam neste processo, no caso uma comunicação para o solicitante da compra de que a mercadoria foi recebida. Se olharmos apenas uma definição genérica do evento do tipo message, temos que um evento deste tipo trata de “uma comunicação entre 2 participantes do processo”.

Partindo deste pressuposto inicial, alguém poderia imaginar uma modelagem como esta:

Perceba que foram utilizados dois eventos do tipo message, um de envio (throw) na raia de Compras e outro de recebimento (catch) na raia do Solicitante.

Qual o problema desta abordagem? Basta nos aprofundarmos um pouco mais na especificação oficial de BPMN (link), para encontramos o seguinte trecho na seção “10.4.1 Concepts“:

“Messages are triggers, which are generated OUTSIDE of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools.”

Em tradução literal: mensagens são gatilhos gerados fora da pool onde estão publicados, descrevendo tipicamente a comunicação B2B entre diferentes processos em diferentes pools.

Assim, o evento do tipo message só deve ser usado para comunicação com participantes EXTERNOS ao processo, não devendo ser utilizado para comunicar com um participante que já faz parte (ou seja, já é uma raia) do processo.

Partindo deste novo conhecimento adquirido, como ficaria então o processo descrito acima? Para isto, precisaríamos saber um pouco mais sobre de que forma é feita a comunicação entre a área de compras e o solicitante. Supondo, por exemplo, que a comunicação fosse realizada como um email disparado automaticamente pelo sistema (ou pelo processo automatizado), poderíamos ter então este desenho:

Neste caso, em vez do par de eventos do tipo message de envio e recebimento, teríamos apenas uma service task indicando o envio de email de forma automática. Perceba que o recebimento de email pelo solicitante não é uma atividade que envolva trabalho (consumo de recurso) de fato. Assim, receber um email é uma situação passiva e consequência direta do envio do email, portanto não é necessário uma tarefa para receber o email na raia do solicitante.

Problemas comuns na modelagem de processos em BPMN – I – Atividades de transferência do processo

Vamos iniciar hoje uma série de artigos que pretendemos publicar ao longo dos próximos meses, falando especificamente de erros, problemas e inconsistências básicas de modelagem, comuns de ocorrer quando começamos a modelar processos e ainda não conhecemos muito bem a notação BPMN.

Pra começar, vamos falar de uma questão muito frequente, que se refere ao encaminhamento de um papel do processo para outro. Vamos imaginar um processo de Viagens, que foi descrito pela área de negócio da seguinte forma:

  1. Um colaborador solicita a viagem
  2. Solicitação de viagem é encaminhada (atenção especial ao uso desta palavra) para uma área interna chamada “Administrativo”, que tem a responsabilidade de pesquisar e mandar cotações da viagem para o solicitante
  3. Cotações são então encaminhadas de volta para o Solicitante avaliar
  4. Se a cotação for aprovada, processo é direcionado novamente para setor Administrativo comprar os tickets, do contrário processo é direcionado de volta para o setor Administrativo refazer as cotações

Agora veja como o modelador decidiu, inicialmente, representar este processo:

Note que no caso da primeira transferência do processo, do papel “Solicitante” para o papel “Administrativo”, foram criadas 2 atividades:

  • Uma atividade na raia do “Solicitante”, chamada “Encaminhar Viagem para Cotação para Administrativo”
  • Uma atividade na raia do “Administrativo”, chamada “Receber Viagem para Cotação do Solicitante”

O mesmo comportamento foi modelado posteriormente, na transferência do papel “Administrativo” para o papel “Solicitante”, com as atividades “Encaminhar Cotações para Solicitante” e “Receber Cotações do Administrativo”, respectivamente.

Este trecho do processo não está errado do ponto de vista da notação BPMN. Mas o que temos aqui, no entanto, são atividades que na prática não precisariam existir. O modelador optou por explicitar a passagem de bastão de um papel a outro através de atividades de transferência do processo, mas isso não é necessário: em BPMN, o próprio fluxo de sequencia já tem o papel de representar/realizar esta transferência de responsabilidade dentro do processo. Neste caso, como ficaria o desenho do processo ajustado? Veja a seguir:
Perceba que com esta mudança, deixamos o processo mais simples e limpo, ao mesmo tempo mantemos o comportamento esperado.

O conceito de utilizar apenas fluxos de sequência para representar a transferência de atividades dentro do processo costuma se aplicar mesmo que exista, de fato, um encaminhamento físico sendo realizado. Por exemplo, este processo de viagens poderia ser realizado em papel, implicando que o solicitante tivesse que levar fisicamente a solicitação impressa e assinada para o setor Administrativo. Mas mesmo neste caso não seria necessário modelar as atividades de transferência. Caso fosse necessário ressaltar este aspecto de encaminhamento físico de algo, poderiam ser utilizados outros recursos para representar, como adicionar uma anotação ao processo ou documentar esta característica do processo nos procedimentos das atividades.

Um cenário em que poderia ser necessária uma atividade para encaminhar ou receber o processo seria num caso em que as atividades são reconhecidamente manuais, realizadas no plano físico, e que possuem procedimentos adicionais, como protocolar a chamada do documento esperado, carimbar, etc. Por exemplo, num processo logístico poderíamos ter uma atividade da área de “Recebimento” chamada “Enviar material para Estoque”, onde “Estoque” é uma área da organização:

Note que, em linhas gerais, continuamos falando do mesmo exemplo citado no Processo de Viagens: a passagem de bastão de uma área para outra. Se o ato de encaminhamento físico do material de um lugar para outro envolve procedimentos adicionais e tem um tempo de execução relevante (vamos imaginar neste caso uma grande planta industrial, em que seria necessário percorrer a distância entre um setor para outro), ou seja, a atividade consome efetivamente recursos, então neste caso faria mais sentido criar uma atividade de transferência.

Fique ligado para outros artigos desta série no futuro! ;-)

Muito prazer, o CLIENTE! (Visão Outside in e Inside out)

Começamos com uma pergunta direta: QUEM É O CLIENTE?
Parece ser uma pergunta um tanto obvia, mas saber exatamente quem é (ou quem são) os seus clientes é fundamental para atender as suas necessidades.

Poderíamos afirmar que:

“Na perspectiva de BPM, cliente é somente aquele que se beneficia da geração de valor e está externo à organização.” (BPM CBOK 3.0, pag.47)

Mas, de uma forma geral, todos nós somos clientes, pessoas comuns que levantam pela manhã para trabalhar, que fazem compras no mercado, utilizam os serviços da rede bancária, que pagam contas, cidadãos que dependem do transporte público para chegar ao seu destino, ou seja, consumidores!

Todos nós, como cidadãos, por exemplo, somos clientes que dependem dos serviços públicos como o acesso à água e a luz, saneamento, limpeza pública e segurança.

Clientes que muitas vezes não têm as expectativas atendidas!

Ao mesmo tempo, quantas vezes, como cidadãos, somos questionados pelo prestador de serviços para saber o que achamos do serviço prestado?

Organizações estão empenhadas em oferecer o melhor valor agregado aos seus produtos e serviços, só que nesta tentativa, trabalham muito mais focados em otimizar e reduzir custos dos seus processos internos e esquecem de avaliar as expectativas dos consumidores destes produtos e serviços.
Assim, saber quem são seus clientes é o caminho para entender suas necessidades, expectativas e o que eles valorizam, e poder produzir e entregar aquilo que seus clientes esperam.

COMO ERA ANTES

Durante décadas organizações determinaram o que seus clientes necessitavam e definiam como seus produtos e serviços seriam disponibilizados. Até então, o cliente era pouco exigente. O foco era: aumento da eficiência na produção.

Esse cenário, de foco na otimização do processo em detrimento às expectativas do cliente, se percebe concretamente nesta célebre frase de Henry Ford, sobre a fabricação do modelo Ford T:

“O carro é disponível em qualquer cor, contanto que seja preto.”

O objetivo de Henry Ford era tornar o carro acessível a todos, aumentando a procura mas ao mesmo tempo reduzindo custos.

Conforme as empresas foram crescendo, foram surgindo novas oportunidades. As empresas foram criando novos planos de expansão e com isto os clientes começaram a impor o que queriam e como queriam. Sendo assim, as estruturas organizacionais e modelos de negócios começaram a tomar novas formas, mas persistia a visão de “dentro para fora”, ou seja, a busca pela eficiência na entrega de valor ao cliente.

OLHAR DE DENTRO PARA FORA OU DE FORA PARA DENTRO?

“Olhar de dentro para fora”: visão conhecida também por Inside out ou ainda por Foco NO Cliente.

É a visão sob o ponto de vista da organização. Se preocupa com o “de dentro”, com foco em seus produtos e serviços. É a organização que determina o que agrega valor para seus clientes e cria a cadeia de valor idealizado por Michel Porter.

Este modelo fazia sentido em sua época, onde a interação com o cliente não era algo comum, pois este ficava em segundo plano. A preocupação das organizações era em fazer as coisas certas. O foco era a eficiência, o controle de custos e a redução de erros.

Atualmente, as organizações estão focadas muito mais na eficácia, ao grau em que os resultados de uma organização correspondem às necessidades dos seus clientes.
Hoje a exigência está muito maior, principalmente no que se refere não apenas a qualidade ou preço dos produtos, mas principalmente ao atendimento real às suas necessidades.

“Olhar de fora para dentro”: visão conhecida também por Outside in ou ainda por Foco DO Cliente.

É a visão sob o ponto de vista do cliente, se preocupando com o que vem de fora, onde o foco é sempre o cliente. É o cliente que determina através de suas experiências aquilo que é importante para a empresa, o que gera valor para concepção dos seus produtos e serviços. A visão do cliente consiste em conhecer a organização pelo lado de fora, tem a ver com o valor percebido, se o cliente está ou não satisfeito.

O gerenciamento de processos consiste na experiência do cliente como ponto de partida para o desenho e implementação de processos. Os processos são desenhados em torno deste relacionamento do cliente com os produtos, serviços e pontos de contatos (momentos da verdade) que devem ser conhecidos pela organização para alcançar a real necessidade e satisfação de seus clientes.

Mas você pode estar se perguntando, como entender de fato as necessidades do cliente? Existe uma fórmula mágica para isto?

O que existe hoje são técnicas e métodos utilizados para “trazer o cliente” para análise e redesenho dos processos, através de coleta de informações como pesquisas de opinião, avaliação dos comentários e reclamações do SAC, comentários enviados por pessoas através de sites como o “Reclame aqui”, e até mesmo workshops e entrevistas envolvendo o cliente. Redesenho é um repensar sob a ótica do cliente, é uma nova visão do negócio. Isso é transformação (construir processos com foco do cliente).

Não se trata mais de apenas oferecer um produto para um cliente, mas de entender a sua real necessidade. O foco assim é a percepção de valor do cliente, o que ele acha que é importante. Esta experiência de consumo leva o cliente a participar da criação do processo ponta a ponta, e permite a organização identificar atividades, que pela visão de “dentro para fora” (inside out), não seriam identificadas.

Vejamos o exemplo da tão conhecida IBM. Empresa de 103 anos de vida, que já passou por altos e baixos em sua história e ainda está no topo das empresas de TI. Mas como explicar sua longevidade? Como ela pode estar viva e próspera em um setor caracterizado pela inovação e a mudança? Dois pontos nos chamam a atenção: a cultura e a mudança.


Thomas Watson
, fundador da IBM, criou sua empresa baseado em três crenças básicas. Achamos relevante destacar uma delas: “Prestar o melhor serviço ao Cliente”. Tinha por base a satisfação e desejo do cliente, ou seja, a crença é direcionada ao cliente e as suas necessidades.

O segundo ponto relevante e mais significativo foi à busca pela mudança, pela transformação.
Em 1991 foi apresentada como a “Nova IBM”, voltada para a visão do mercado atual e obcecada pela qualidade. Segundo a própria IBM, a mudança foi causada pelo aumento do nível de exigência dos seus clientes, o que gerou a necessidade de criar valor para seus clientes.

A IBM de hoje não se considera uma empresa de tecnologia, mas uma empresa que resolve business problems usando a tecnologia. Segundo a IBM, ela não vende “brocas”, vende ferramentas para produzir “buracos na parede”, a IBM é focada nos trabalhos que seus clientes precisam que sejam realizados.

Quem já assistiu o filme “Quero ser Grande” (Big, 1988) estrelado Tom Hanks, percebe uma ligação da história com a visão “outside in”.

No filme, Josh (Tom Hanks) se torna adulto da noite para o dia, e conhece o Sr. MacMillan, dono de uma empresa que fabrica brinquedos (naquela clássica cena do The Big Piano). Confira aqui a cena do filme.

O dono da empresa comenta com ele sua preocupação de que não estão obtendo boas vendas, e Josh acaba ganhando o emprego porque começa a expor para a empresa a visão do cliente (ele como criança em corpo de um adulto).

Com o foco do cliente, os produtos desenvolvidos pela empresa se tornam muito mais atraentes aos consumidores, e a empresa volta a gerar crescimento.

O foco hoje não pode ser mais o produto ou o lucro que este lhe proporciona, mas a experiência vivida pelo cliente ao consumi-lo. O cliente de hoje procura ser compreendido e ter suas expectativas atendidas. Para a organização fica a responsabilidade de conhecer seu cliente e entender porque ele procura pelo seu produto ou serviço. Conhecer o cliente e atender suas necessidades é um desafio, e deve ser encarado como uma grande oportunidade de crescimento para a empresa e para a geração de novas soluções inerentes ao mercado atual.

Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2

No primeiro artigo da série (veja aqui) falamos sobre os métodos Pesquisa, Entrevista e Observação Direta. Neste segundo e último artigo da série abordaremos o restante dos métodos utilizados para coleta de informações para o trabalho de modelagem.

WORKSHOP ESTRUTURADO

Workshop estruturado é um método utilizado para a coleta informações através de reuniões com os representantes dos papéis envolvidos no processo, reunindo diferentes pontos de vista, visando o detalhamento e a modelagem do processo de modo interativo.

photo credit: juhansonin via photopin (cc)

Agendamento do workshop

A escolha correta dos envolvidos é crucial para uma reunião produtiva, mas afinal como escolher as pessoas certas para a reunião?

  • Especialistas: Ninguém melhor para explicar um determinado processo do que as pessoas que trabalham nele. São os executores do processo, usuários do sistema ou membros de equipes operacionais com profundo conhecimento sobre certas funções ou operações de negócio. Quando em grande número são representados por usuários-chaves que se fazem presente no workshop. Representados normalmente pelos papéis de Representantes Funcionais ou Gestores Funcionais.
  • Liderança: Outro papel de importância na reunião é o do Dono do Processo, este é o responsável pelo processo ponta a ponta. Defende as prioridades e assegura que o processo atenda às expectativas de desempenho esperado pelo cliente. Não podemos esquecer também do Patrocinador, representado usualmente pela liderança executiva, gestores, diretor ou gerente da área responsável pelo processo. Apesar de não se envolver de forma integral, participa geralmente de reuniões estratégicas que determinam o caminho que o processo irá trilhar. Estes papéis possuem uma visão macro do processo.
  • Facilitador: Normalmente representado pelo Analista de Processos ou Designer de Processos. É o responsável pela condução adequada da reunião e por garantir que todos os participantes sejam ouvidos. Para isto deve ter a habilidade para lidar com pessoas, resolver conflitos e manter o foco no objetivo do workshop.

A divisão apresentada acima contendo especialistas, liderança e facilitador compreende uma abordagem mais estruturada e pode variar de empresa para empresa, levando em conta a sua maturidade em BPM. O mesmo vale para as convenções de nomenclaturas para os papéis descritos.

Outras questões que devem ser levadas em conta para escolha dos envolvidos:

  • O participante do workshop deve ter a competência e o conhecimento necessário para descrever suas atividades e se posicionar quanto suas divergências.
  • Os envolvidos devem ter bom relacionamento, para isto o facilitador deve se informar sobre conflitos de interesses e embates políticos entre gestores e equipes.
  • Disponibilizar uma agenda viável para todos os participantes.

Vantagens

  • Redução do tempo de desenvolvimento do modelo devido ao entendimento comum criado entre os participantes.
  • Resolução de conflitos no momento do workshop.
  • Redução do número de intermediadores evitando futuros problemas de comunicação.
  • Redução do tempo do acompanhamento das partes envolvidas na evolução do modelo final.
  • Facilitador com habilidades de técnicas de modelagem.
  • Facilitador com apoio de Designer de Processos (trabalho em dupla) na modelagem do processo; principais impactos na redução do tempo de execução e validação do modelo com processo aprovado na mesma reunião.

Desvantagens

  • Desgastes em deslocamentos / viagens – Participantes muitas vezes encontram-se em locais físicos distintos.
  • Altos custos de viagens.
  • Conciliar agenda dos participantes.
  • Custo com hora/homem  – 100% do tempo de todos ao mesmo tempo em reunião.
  • Evitar paralisia por análise – Seleção do escopo e escolha do processo e profundidade da análise devem ser definidos com muita clareza.

CONFERÊNCIA VIA WEB photo credit: JulianBleecker via photopin (cc)

A Conferência via web ou Videoconferência como também é conhecida, é um método semelhante ao Workshop Estruturado. Utilizado quando os participantes estão em locais físicos distintos e sem a disponibilidade para viagens.

Vantagens

  • Redução de custos de deslocamentos e viagens.
  • Redução no tempo de deslocamentos entre unidades.
  • Utilizado para se buscar um consenso sobre um mesmo processo desenvolvido em diferentes unidades.

Desvantagens

  • Não funcionam muito bem com grupos grandes.
  • Dificuldade de conduzir a participação individual dos participantes.
  • Baixa qualidade de áudio e vídeo.

Atenção para a infraestrutura tecnológica requerida que dependerá da necessidade de cada projeto/empresa. Alguns pontos devem ser observados:

  • Disponibilidades de equipamentos/periféricos de áudio e vídeo.
  • Qualidade de velocidade de banda da internet para transmissão, disponibilização de vídeo e eventuais imagens, acompanhamento em tempo real do processo que está sendo modelado.
  • Softwares apropriados para conferência.

FAZER EM VEZ DE OBSERVAR

photo credit: ColorTime via flickr (cc)

Método conhecido também como “aprendizado do aprendiz”, muito utilizado em tarefas repetitivas. Consiste em aprender o que é feito e então executar o processo.

Ao ensinar as atividades, podem surgir informações de tarefas e passos que ocorrem de forma inconsciente, isto permite que o observador tenha um conhecimento mais detalhado das tarefas realizadas.

A execução do processo pelo observador pode ajudar a coletar alguns detalhes das atividades que de outra forma não seriam observados. Sempre que possível, é interessante ter um segundo membro da equipe observando o processo de aprendizagem para auxiliar na identificação de detalhes das atividades.

ANÁLISE DE VÍDEO photo credit:  Flickmor via flickr (cc)

Similar à observação direta  (veja mais sobre o método Observação Direta no artigo anterior), a análise de vídeo auxilia na identificação de evidências à distância e permite que o executor realize suas atividades de forma mais natural.

A presença de um equipamento de gravação permite uma adaptação mais rápida do que a de um observador ao seu lado.

Outra vantagem é que os vídeos podem ser mais tarde assistidos pelo executor e este narrar suas atividades e ações executadas fora do campo da lente, isto auxilia na identificação de informações não vistas pelo observador.

SIMULAÇÃO DE ATIVIDADES

photo credit: Wonderlane via flickr (cc)

A simulação de atividades é utilizada para identificar possíveis falhas humanas e desvios na execução do processo. Uma forma de simulação seria, durante a entrevista ou workshop, a realização de uma análise apurada do comportamento de cada atividade do fluxo do processo. Esta análise consiste em avaliar o que dispara esta atividade (entradas), seu resultado (saídas) e regras estabelecidas para execução desta atividade.

 

Como falamos nos dois artigos, cada método tem suas vantagens, desvantagens e o esforço necessário para que possa ser realizado. Questões como tempo requerido, altos custos de viagens, conciliar agenda dos participantes, suporte à infraestrutura tecnológica e habilidades em técnicas de modelagem são apenas alguns pontos a serem observados antes de optar pelo método a ser utilizado no levantamento de informações.

Não há um método único que seja melhor, cada projeto de modelagem ou análise de processos deve considerar quais métodos de coleta de informações são mais apropriados e eficazes para o processo que está sendo estudado.


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual

Em sua riqueza de elementos para a representação de processos de negócio, a notação BPMN traz uma classificação de tipos de tarefas.

Elas ajudam a identificar a forma como a tarefa deve ser executada:

Estes elementos e seus comportamentos esperados estão descritos na especificação BPMN (disponível em http://www.omg.org/spec/BPMN/Current). Apesar disto, a identificação de quando usar cada tipo de tarefa ainda é alvo de alguma ambiguidade.

Em uma série de três artigos, trataremos estes tipos de tarefas com mais detalhes para esclarecer as dúvidas comuns. Para facilitar o entendimento, trataremos os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefa abstrata

A tarefa abstrata (abstract task) é a tarefa sem tipo específico.

Tarefa abstrata (abstract task)

Sobre ela, a especificação diz:

“Uma tarefa sem nenhum tipo de especificação é chamada tarefa abstrata (Abstract Task) (ela era referenciada como None Task em BPMN 1.2).” (pag. 154)

Ou seja, a tarefa abstrata (abstract task) pode ser utilizada em modelagens cujo tipo de tarefa ainda não está definido ou em casos onde a tipificação da tarefa simplesmente não se faz necessária. É o caso dos processos executados manualmente.

Um processo de negócio modelado com tarefas abstratas.

Tarefas de interação humana

Para representar tarefas cuja execução envolve a atuação de pessoas em um processo, BPMN sugere dois tipos de tarefa: a user task (tarefa de usuário) e a manual task (tarefa manual).

Tarefa manual (manual task) e Tarefa de usuário (user task)

O que a especificação diz sobre estes tipos de tarefa:

“Uma Tarefa de Usuário (User Task) é uma tarefa típica de “workflow” onde um ator humano desempenha a tarefa com a assistência de uma aplicação de software e é disponibilizada através de uma lista de de trabalho ou outra forma de gerenciamento semelhante. ” (pág 160)

“Uma Tarefa Manual (Manual Task) é uma tarefa que é esperada que seja executada sem o suporte de nenhuma aplicação de execução de processos de negócio ou outra aplicação. Um exemplo disso pode ser um técnico de telefonia instalando um telefone no endereço de um cliente.” (pág 161)

“10.3.4.1 Tarefas com o envolvimento humano
Em muitos fluxos de trabalho, o envolvimento humano é necessário para executar certas tarefas especificadas no modelo de fluxo de trabalho. BPMN especifica dois tipos de tarefas com o envolvimento humano, a Tarefa Manual (Manual Task) e a Tarefa de Usuário (User Task).
A tarefa de usuário é executada e gerenciada por um motor de execução de processos de negócio. Atributos relativos ao envolvimento humano, como as pessoas envolvidas e a renderização de interfaces de usuário (UI) podem ser especificados em grande detalhe.(…)
Uma tarefa manual é uma tarefa que não é gerenciada por qualquer mecanismo de processo de negócio. Ela pode ser considerada como uma tarefa não gerenciada, não gerenciada no sentido de que o motor de processos de negócio não acompanha o início e o fim de tal tarefa.
Um exemplo disso poderia ser uma instrução de papel como base para um técnico de telefonia instalar um telefone em um local do cliente.” (pág 165)

 

Ou seja, uma user task (tarefa de usuário) é a tarefa que é executada através de uma aplicação e gerenciada por uma lista de trabalho(1). Em outras palavras, é a tarefa realizada através de uma aplicação, como um BPMS (Business Process Management Suite), uma aplicação de workflow, uma ferramenta de gestão de cronograma ou qualquer outro sistema que apoie o controle do processo.

Já as tarefas manuais (manual task) são aquelas executadas no mundo físico, sem o controle por parte de uma aplicação.

Aqui há uma confusão comum na interpretação do “uso de uma aplicação”, inclusive replicada em literatura. Para entender claramente a diferença entre elas, é preciso compreender que o que define se uma tarefa é user ou manual task não é se usamos alguma ferramenta para executá-la, e sim se há um sistema controlando a sua execução.

Isto quer dizer que, se temos por exemplo um processo de venda de produtos que é todo executado manualmente, mas em uma determinada atividade uma planilha eletrônica é usada para calcular o valor a ser cobrado do cliente, e um e-mail é enviado ao cliente com o orçamento do produto, ainda assim (apesar de usar uma aplicação de planilha e o software de e-mail para o trabalho) esta será uma tarefa manual, pois não há controle nem gestão sobre quem faz, quando iniciou e quando concluiu a tarefa.

Mesmo utilizando ferramentas como planilha eletrônica e email, ainda assim a tarefa "Apresentar orçamento" neste processo é manual.

Numa modelagem de processo que não será automatizado, e que portanto são pessoas que lerão e interpretarão o modelo, não faz muito sentido essa diferenciação, já que as pessoas, ao lerem a documentação do processo, têm condições de interpretar o modelo mesmo que os tipos de tarefas não estejam esclarecidos.

Na modelagem para automatização, entretanto, isso é muito importante. A tarefa de usuário é aquela em que o processo deve aguardar que um usuário informe o resultado do trabalho, registrando que a mesma foi concluída para então dar seguimento ao fluxo do processo. Já sobre a tarefa manual o sistema não tem nenhum controle, então mesmo que ela seja incluída no modelo, ele “passará batido” por ela.

Por exemplo:
Considere novamente o processo de atendimento de chamado, no qual há uma atividade para um técnico de telefonia para realizar uma visita técnica ao cliente, e que este processo terá sua execução controlada por uma aplicação (por exemplo um BPMS).

Neste processo, podemos ter dois cenários:

Cenário 1: O Técnico acessa uma lista de tarefas, com todos os chamados a realizar, identifica o chamado que está executando e finaliza a tarefa. Com isso, o sistema identifica que a mesma foi concluída e segue o fluxo disponibilizando a próxima tarefa ao respectivo ator responsável. Neste caso, a tarefa está sendo controlada pelo sistema (seu início e fechamento), portanto é modelada como uma tarefa de usuário.

Cenário 2: O Técnico não acessa o sistema. Ele pode, por exemplo, receber ao início do dia uma lista impressa com todos os clientes a visitar. A cada visita, o cliente assina o papel confirmando que o atendimento foi realizado. Ao fim do dia, quando o técnico retorna para a empresa, ele entrega a lista ao Atendente, que então verifica se o atendimento foi realizado e registra no sistema o resultado do atendimento. Neste caso, a tarefa do técnico é modelada como uma tarefa manual, para que fique visível aos que olham o modelo em que momento o mesmo realiza seu trabalho (e que, do ponto de vista do processo de negócio, existe uma dependência da tarefa de "Verificar resultado do serviço" em relação à "Realizar visita técnica", mas o sistema não controla o início nem o fim do trabalho realizado.

Assim, concluímos que, na modelagem com a notação BPMN, o tipo de tarefa não é definido pelo uso de sistemas para realizá-la, e sim se há alguma aplicação sendo utilizada para controlá-la.

_______

(1) Processos podem ser controlados por aplicações de diferentes tipos. Isto já foi tema deste blog no artigo Gerenciando a execução de processos com (ou sem) um BPMS.

 


Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Modelagem de Processos de Negócio: Diferenças entre diagrama, mapa e modelo de processos

Quantas vezes você já se referiu ou ouviu pessoas se referirem a um mesmo desenho de processo como sendo um diagrama de processo ou mapa de processo ou ainda, como um modelo de processo?

Este é um assunto controverso, principalmente para pessoas que estão começando em projetos que envolvem iniciativas de processos de negócio ou iniciando o estudo de BPM.

Dúvida comum que é esclarecida em nosso curso de Modelagem de Processos de Negócio (iPE01). Constatamos que os termos diagrama, mapa e modelo de processos são utilizados, por muitas vezes, de forma errônea, como sinônimos, porém eles na verdade tem diferentes propósitos e aplicações.

Falaremos neste artigo sobre os três níveis de modelagem (diagrama, mapa e modelo), as diferenças em seus desenhos, no nível de detalhamento e utilidade de cada um.

Diagrama, mapa e modelo são três níveis de “representação” de processos.

Estes três níveis de representação de processos diferem-se em níveis de abstração, informação, utilidade, precisão, complexidade, padronização de elementos do fluxo, evolução e amadurecimento do desenho proposto.

diagrama, mapa e modelo de processos

Fazendo uma analogia com mapa geográfico, podemos dizer que o diagrama de processo demonstra a rota que é realizada em uma visão simplificada, com o trajeto percorrido, evidenciando os principais pontos de referência, o local de origem e destino. O mapa do processo apresenta a rota de forma mais detalhada, com elementos como nome de avenidas, ruas, principais pontos de referências, opções de rotas alternativas, trajeto e tempo estimado para cada rota. O modelo de processo apresenta a rota de forma mais completa e precisa, descrevendo a situação atual do trânsito, rota de transporte público, clima na região da rota, além de fotos das avenidas e ruas.

O Diagrama é uma representação inicial do processo. Ele demonstra o fluxo básico focando as principais atividades. Não trata exceções ou falhas no processo.

Utilizado para capturas rápidas no processo, por isto não é muito preciso.
Ajuda a obter entendimento rápido das principais atividades, representando ideias simples em um contexto alto nível.

Esta representação inicial do processo pode significar várias coisas. O diagrama pode representar um macroprocesso organizacional, por exemplo, como também se tratar de apenas um esboço (versão inicial do processo) de uma primeira avaliação.

diagrama de processo

Em um primeiro momento busca-se conhecer os processos identificando as atividades chave. Esta é uma das técnicas mais utilizadas para conhecer os processos organizacionais, conhecida como abordagem top-down, em uma visão de macroprocessos (visão interfuncional) até chegar aos processos operacionais.

Em uma primeira versão, o processo muitas vezes não recebe as informações necessárias para partir diretamente para um nível de mapa ou modelo. Fatores como a precisão e nível de detalhamento influenciam a forma como o processo é modelado. A precisão varia de acordo com a profundidade em que se avalia cada aspecto do processo e suas atividades, e aumenta de acordo com o número de pessoas entrevistadas das áreas que fazem parte dos processos.

O nível de detalhe define o quanto cada processo, sub-processo, atividades, tarefas, procedimentos, atributo ou aspecto é descrito.

O mapa é uma evolução do diagrama, acrescentado de atores, eventos, regras, resultados e um detalhamento do processo. Ampliada para uma visão mais detalhada, o mapa fornece informações de maior precisão do desenho do processo.

Neste nível as atividades do processo e seus objetivos estão mais claros. Foram identificadas as responsabilidades atribuídas ao longo do processo. Isto se deve aos métodos de levantamento de informações utilizadas pela equipe envolvida na iniciativa de BPM.

Através de pesquisas a equipe obteve um entendimento inicial, e segue para as entrevistas com os envolvidos no processo (donos de processos, clientes, fornecedores, pessoas que trabalham no processo, etc). Esta etapa é de grande importância para identificação das regras, validações, caminhos de exceções, papéis e detalhamento de atividades.

Existem diversos métodos para levantamento de informações, como workshops, conferências, observações diretas, etc. Abordaremos este assunto em um próximo post.

A escolha do nível de representação de processos dependerá do propósito da modelagem, em muitos casos, o diagrama ou mapa já são suficientes para representar o processo.

O modelo é a versão final da evolução do processo. Esta representação traz um alto grau de precisão e detalhamento do processo.

Uma grande vantagem é a capacidade de execução do processo através de simulações. Estas simulações geram informações que acercam o desempenho do processo, úteis para analisar/validar a execução do processo.

Este nível de execução requer uma descrição detalhada dos atributos do processo, descrevendo propriedades e características das entradas/saídas, procedimentos/passos, recursos, custos, alocação, simulação, parâmetros de duração, etc. Estes atributos podem ser classificados em categorias e sua documentação varia de acordo com o objetivo da modelagem realizada.

A partir do modelo é possível executar as próximas etapas do ciclo de gestão por processos, como a análise, redesenho, reengenharia, melhoria continua e medição do processo.

Você se interessou pelo assunto?

A área de conhecimento de modelagem de processos fornece o entendimento dos propósitos, benefícios, habilidades e técnicas e é muito utilizada pelas organizações para conhecer, documentar e melhorar processos.
Este tema é explorado com mais profundidade em nosso curso de Modelagem de Processos de Negócio, onde abordamos de forma mais abrangente o tema. http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

 

A diferença entre “desenhar” e “modelar” processos

Não basta saber usar um editor de textos para ser um bom escritor.
O mesmo se dá na relação entre uma ferramenta de modelagem e o designer de processos(1).

Pode parecer estranho começar um artigo com uma afirmativa como essa. Mas o fato é que muitas vezes já nos encontramos em conversas com pessoas envolvidas em iniciativas de processos com a expectativa que, se treinassem pessoas da empresa para usar alguma ferramenta para desenhar de processos (como o Bizagi, por exemplo), isso bastaria para que essas pessoas pudessem documentar os processos das suas áreas (e assim teriam modelados os processos da organização).

Mas criar um bom modelo de processo é como escrever um bom texto. Não basta apenas dominar o editor de textos e saber escrever as palavras, é preciso preocupar-se com a clareza do conteúdo – em como ele será interpretado por quem o lerá.

Designer de processos em ação.

O primeiro passo para uma boa escrita é conhecer e aplicar bem as regras gramaticais da linguagem usada. Uma vírgula fora do lugar pode mudar completamente o sentido de uma frase. Da mesma forma, um elemento BPMN aplicado sem a preocupação com as regras da sua especificação também pode levar a interpretações distintas dos leitores em relação à expectativa de quem fez a modelagem.

As definições da especificação BPMN funcionam como as regras gramaticais de um idioma. Se forem bem conhecidas por quem as usa podem ser relativamente fáceis de aplicar, já que são bastante claras. Elas definem como são os símbolos, como podem se conectar e o que significam.

Conhecer as regras de uso de um idioma ou de uma notação são apenas o primeiro passo para comunicar-se bem com quem lerá o produto do trabalho. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las ao conteúdo que queremos transmitir.

Em uma história bem contada, a sequência de fatos, determinada pelo enredo, é fundamental para o seu entendimento. Em algumas situações, fatos podem ser contados em paralelo, em outros casos eles têm uma sequência que se for quebrada pode dificultar a compreensão ou mesmo gerar interpretações equivocadas.

Na modelagem de processos, a lógica do processo é o enredo. Ela se define tendo um evento que sinaliza o início da estrutura de precedência entre as atividades e regras de roteamento do fluxo, que podem apresentar cenários com sequências de atividades paralelas ou alternativas, até atingir o seu fim. É ela que determina como os elementos da notação devem ser usados para criar o diagrama do fluxo do processo. Toda a modelagem deve ter em vista garantir a integridade da lógica do processo.

Assim como a boa escrita, isto é fruto de uma habilidade desenvolvida com a prática. Esta habilidade se constrói:

  • desenhando processos,
  • tendo a sensibilidade de lê-lo sob a perspectiva do leitor,
  • validando – não apenas gramaticalmente mas também a lógica representada junto com as outras pessoas envolvidas
  • e discutindo a modelagem proposta com outros analistas, avaliando até mesmo outras alternativas de transmitir mais claramente a ideia do processo.

Esse trabalho envolve alguns cuidados que o designer de processos deve observar em suas modelagens se quiser apresentar resultados claros, objetivos e precisos na representação de processos:

  • Criar modelos limpos. Diagramas de processos devem primar pela interpretação fácil com olhar simples. Isto se obtém evitando-se desenhar linhas sobre linhas, cruzar linhas sobre as outras ou traçar conexões entre elementos muito distantes. Isso pode ser resolvido com o uso de elementos de links (mas use com parcimônia!) e alguma reorganização (avalie se as lanes onde os elementos que devem se conectar não podem ser aproximadas). Usar nomes breves e objetivos para eventos, gateways e atividades também ajudam a manter o diagrama limpo.
  • Aplicar boas práticas. Existem diversas práticas, que foram sendo agregadas por profissionais com experiência na modelagem de processos e que são recomendadas no uso da notação. Confiar nessas práticas pode facilitar o trabalho e ajudar na elaboração de diagramas eficazes na comunicação.
  • Usar a notação de forma padronizada. Padronizar a forma como usa a notação dá harmonia ao conteúdo representado, gerando conforto a quem lê e confiança de que o processo está bem modelado.
  • Modelar no grau de detalhamento apropriado. De acordo com o propósito da modelagem do processo, o diagrama requer uma representação em maior ou menor nível de detalhe. Algumas situações requerem um processo desenhado numa perspectiva superficial, suficiente para dar entendimento ao negócio, enquanto outras requerem detalhamento no nível de atividade da operação, ou mais além, em que todas as exceções do processo sejam previstas e tratadas. Compreender o grau de detalhamento esperado – e mantê-lo no decorrer de todo o fluxo modelado -, é um cuidado fundamental.

Encontre uma pessoa com habilidades de compreensão gramatical e boa escrita e você terá nela um excelente profissional para modelar seus processos. Desenvolva estas habilidades e você será esta pessoa.

_____
(1) De acordo com BPM CBOK v3 em português, “Designer de Processos” é o papel realizado por um membro da equipe de modelagem de processos cujo trabalho é desenhar novos processos e transformar processos de negócio. Tipicamente possui habilidades analíticas, criativas e de descrição visual e lógica dos passos de processos e na forma de organização do trabalho. Não é uma função, mas um papel, que pode ser realizado por um profissional específico ou mesmo pelo analista de processos ou de negócios.

Projetos de Modelagem de Processos – Parte 1: Objetivos e Motivadores

A modelagem de processos está sendo muito utilizada pelas organizações para conhecer, documentar e melhorar os seus processos. Porém, as necessidades que levam uma organização a iniciar a modelagem de processos acabam direcionando a tipos de projetos de modelagem com focos diferentes.
Trataremos, neste primeiro artigo da série, dos principais objetivos e motivadores relacionados aos mais comuns tipos de projetos de modelagem de processos.

 

Modelagem para Conhecer o Processo:

Objetivo
  • modelar o processo de modo que a forma como ele é realizado passe a ser de conhecimento dos participantes que executam o processo e da organização como um todo
Motivadores
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Documentação ou Treinamento:

Objetivos
  • documentar o processo para que dúvidas operacionais possam ser diluídas através da consulta ao processo
  • fornecer uma documentação completa para que os seus executores saibam como realizar suas atividades, evitando erros ou demoras devido a dúvidas
  • fornecer uma documentação que facilite o treinamento de novos colaboradores:
    • minimizando o efeito de perdas de colaboradores
    • auxiliando a organização que passe por um processo de expansão
Motivadores
  • processos em que os executores não tem experiência em executá-lo porque:
    • os papéis tem alta rotatividade ou
    • o processo não é executado com frequência por determinados papéis
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Implantação de Auditoria:

Objetivo
  • descrever os processos que serão objetos de auditoria para que exista uma referência comum sobre o que deve ou não ser feito no processo
Motivadores
  • padronização e documentação de processos que precisam ser auditados devido a exigências internas ou externas da organização
Mapeamento de Processos de Toda a Organização:

Objetivo
  • criar um repositório de processo com todos os processos da organização modelados e documentados
Motivadores
  • criar um ponto de partida para as iniciativas de gestão por processos
  • permitir que novas demandas de melhoria de processos possam ser atendidas rapidamente
Modelagem para Padronização dos Processos:

Objetivo
  • garantir que toda a organização executa o mesmo processo
Motivadores
  • demandada por processos executados em mais de um local. Ex.: Processo utilizado em várias unidades geográficas como no varejo ou no sistema financeiro.
  • processos que possuem diferente desempenhos de acordo com o local onde são executados ou das pessoas que os executam
  • aquisição de outras empresas → Necessidade de unificar a operação
  • abertura de novas unidades → Necessidade de replicar o modelo de gestão
Modelagem para o Redesenho de Processos:

Objetivos
  • a modelagem é focada no entendimento da situação atual do processo (AS IS)
  • objetivo não é a documentação do processo e sim o entendimento de
    • quais são suas atividades
    • quais os seus pontos fracos
    • quais os seus pontos fortes
    • quais suas oportunidades de melhoria
  • criar base para executar todo o ciclo BPM de melhorias: Mapeamento, Redesenho, Automação, Implantação e Melhoria Contínua.
Motivadores
  • redução de custos ou perdas do processo
  • processos críticos que, se não forem bem executados, podem gerar um grande impacto na organização
  • processos com metas cronológicas bem delimitadas
  • processos que possuem muitas perguntas a serem respondidas. Ex: Como é feito o processo? Porque acontecem tantos erros? Porque o processo é tão lento? Como posso melhorá-lo? Como meço os indicadores deste Processo?
  • processos com SLA bem definidos
  • melhorar o atendimento ao cliente final
  • expansão organizacional
  • processos inter-organizacionais (B2B)
  • empresa precisa se certificar ou aderir a uma legislação
Modelagem para Automação de Processos:

Objetivo
  • conhecer o processo o suficiente para propor uma versão automatizada que busque aumentar a sua eficiência operacional
Motivadores
  • ocorre quando a organização está satisfeita com o seu processo, mas acredita que ele poderia ser melhorado com o uso da tecnologia
  • organização entende que não precisa necessariamente discutir o processo a nível de negócio, e sim entregar com mais eficiência o processo da forma como atua hoje

Leia também o artigo Parte 2 – Características e Desafios, que trata da profundidade da modelagem, características, desafios e riscos relacionados a cada tipo de projeto de modelagem.

BPMN: Uma atividade para mais de um participante do processo

Há uma questão recorrente na modelagem de processos relacionada à distribuição de atividades nas lanes de processo: como representar um trabalho sendo realizado por mais de uma pessoa?

Por exemplo:
Digamos que em um processo há uma reunião realizada entre o Diretor de Planejamento e o Diretor Financeiro, que recebem uma proposta de um analista e realizam uma reunião para avaliar sobre o investimento. A seguir, eles atuam na priorização das ações relacionadas ao investimento, e a partir desta priorização são realizadas outras ações.

Para essa situação em que há dois participantes envolvidos na realização de uma mesma tarefa, já vimos diagramas que tentam representar isso de algumas formas peculiares:

"Tentei demonstrar que as atividades são realizadas pelos dois usuários posicionando-as sobre o limite entre as duas lanes."

A abordagem acima é inadequada sob o ponto de vista de uso da notação BPMN e poderá gerar interpretações diferentes. Para a notação, uma atividade só pode estar associada a uma raia (lane), e mesmo que a ferramenta de criação do diagrama não aponte o problema na validação do processo, o fato é que internamente as atividades estão vinculadas a apenas uma lane. Isto está estabelecido na própria especificação da notação. Se a ferramenta utilizada dispõe de geração de relatório que lista quais tarefas estão relacionadas a quais lanes, essas tarefas só estarão associadas a um único participante.
Tem um outro problema ao se praticar o mapeamento desta forma: e se os investimentos tivessem que envolver também o Diretor de Tecnologia – como colocar as tarefas compartilhando pessoas de três raias?

Outra tentativa comum é a refletida no exemplo abaixo:

"Coloquei as tarefas em paralelo porque eles fazem a reunião ao mesmo tempo."

No diagrama acima, as regras de validação lógica do uso da notação também não apontariam problema, mas o processo ainda não estaria corretamente representado.

A interpretação que se deve ter no uso do gateway paralelo não é de que as atividades paralelizadas serão realizadas ao mesmo tempo, e sim que elas podem ser feitas em paralelo porque não há restrição de dependência entre elas. Assim, apesar de serem iguais no exemplo acima, cada tarefa tem sua execução própria, levando ao entendimento que cada um fará as atividades quando tiver disponibilidade. Por exemplo: digamos que o Diretor de Investimentos faça “Avaliar investimento” pela manhã e já siga para a próxima tarefa, enquanto o Diretor Financeiro só consiga iniciar a tarefa “Avaliar investimento” à tarde. O processo mapeado acima permite essa interpretação.

Se a ideia é de que os dois realizem juntos a tarefa “Avaliar investimento” e “Priorizar etapas do investimento”, recomendamos uma forma de mapear isto um pouco diferente:

Uma raia com um papel em grupo que abstrai os participantes e garante que as tarefas sejam realizadas em conjunto pelos envolvidos.

Nesta abordagem, criamos uma raia para um papel que abstrai um grupo (o  ”Comitê de Avaliação de Investimentos”), e atribuímos as atividades a ela. Na descrição da raia, ficam estabelecidas as regras usadas para definir quem são os participantes do comitê – que neste caso será formado pelos Diretores de Investimentos e Financeiro. Esta abordagem ainda possibilita que outros diretores possam se juntar ao comitê sem impactar no diagrama do processo, bastando apenas ajustar a descrição dos participantes do grupo.