Modelando a Arquitetura de Processos da Organização

Para muitas organizações, um passo fundamental para estabelecer seu conhecimento sobre o negócio é a modelagem dos processos de ponta a ponta. Mas sem uma estruturação deste modelo o resultado desta atividade dificilmente será aplicável pela organização.

Um caso emblemático que aconteceu há alguns bons anos atrás, foi quando recebemos um processo modelado por um profissional externo contratado pelo cliente que chegou às nossas mãos para que propuséssemos uma solução de automatização com um BPMS. Nada fora do comum, exceto que o diagrama em questão, modelado em BPMN, possuía em torno de 60 raias, mais de 750 tarefas operacionais, e estimamos que em torno de uns 10km de setas conectando os elementos entre eventos, atividades e gateways. O fluxo era o produto de um ano e meio de levantamento de informações do profissional cuja intenção era representar no diagrama todo o trabalho realizado pela organização.

Não é preciso dizer que o desenho de processo criado foi pouco proveitoso, pois para entender uma parte qualquer da atividade do negócio era necessário percorrer as linhas com os dedos e dar sorte de chegar até ela seguindo os gateways corretos – quase como um labirinto.

O que faltou?
Faltou abstrair a visão do negócio através de uma uma Arquitetura de Processos.

Entendendo a Arquitetura de Processos

O conceito de arquitetura e o valor que ela proporciona ao negócio são muitas vezes mal compreendidos. Por exemplo, no que diz respeito a casas e outros tipos de edifícios, a arquitetura é usada para identificar e definir, em vários níveis de detalhe, os componentes de fundação, estrutura, cobertura, encanamento, elétrico e interior e como eles são montados. Da mesma forma, com relação aos negócios (e no contexto do Business Process Management), a arquitetura é usada para identificar e definir os componentes que compõem os negócios e os relacionamentos entre esses componentes, ou seja, produtos e serviços, recursos, processos e procedimentos, clientes, organizações, funções, produtos de trabalho, locais, eventos, regras de negócios, sistemas de informações, metas, indicadores de desempenho e assim por diante. [ABPMP BPM CBOK 3.0, Cap 2. Design de Processos]

Então, na modelagem de processos, a arquitetura é um arranjo dos modelos de processos em uma estrutura que descreva todo o negócio através das suas partes componentes. Ela pode ser criada atendendo estruturas (framworks) já bastante conhecidos, para reduzir a ambiguidade do conhecimento sobre o negócio, como por exemplo o The Zachman FrameworkTM, The Open Group Architecture Framework (TOGAF), Department of Defense Architecture Framework (DoDAF) ou modelos de referência.

Uma Arquitetura de Processos Corporativa possibilita:

  • visualizar a integração dos processos em nível estratégico/corporativo com a possibilidade de dar um “zoom in” sobre uma atividade de negócio específica para compreender como ela acontece na organização (processos de trabalho e processos operacionais)
  • compreender as dependências existentes entre processos e mapear os impactos de uma mudança em todos os componentes que afetam a execução dos processos de negócio e a entrega de valor ao cliente.
  • identificar e corrigir problemas ocasionados por mudanças não planejadas, que afetam o desempenho do processo e as metas de entrega de produtos e serviços.
  • avaliar que processos e componentes já existem e que podem ser aproveitados ou devem ser redesenhados para gerar a oferta de um novo produto ou serviço.
  • definir indicadores de gerenciamento em níveis de abstração diferentes, podendo medir da efetividade do negócio (ou “estamos fazendo as coisas certas”) em um nível mais estratégico, até a sua eficiência (ou “estamos fazendo certo as coisas”), obtido da visão de processos em nível funcional ou operacional.

Entre outras aplicações importantes para uma organização que está desenvolvendo sua maturidade em processos de negócio.

Exemplo de desdobramento da Cadeia de Valor em uma Arquitetura de Processos, do nível estratégico ao nível tático (exemplo aplicado no curso de Modelagem de Processos de Negócio da iProcess Education).

Estruturando a Arquitetura de Processos da Organização

Não há um modelo de referência específico que sirva para qualquer organização ou número de níveis recomendados na criação de uma Arquitetura de Processos. Na verdade, a arquitetura trata muito menos de “quantos níveis de detalhe” devem haver e sim foca no que cada nível deve representar.

Organizar a arquitetura de processos em níveis de abstração possibilita que a organização identifique oportunidades para melhoria através do desdobramento em níveis incrementais de detalhamento, enquanto compreende como a cada atividade da operação realizada se encaixa no negócio ao elevar gradativamente o nível de abstração.

Assim, vamos explorar os diferentes tipos de visões que podem ser interessantes de serem organizados na arquitetura. Cada uma das visões a seguir representa um determinado nível de abstração sobre o negócio da organização.

Visão Estratégica (ou Visão Corporativa) | Atividade do Negócio

Apresenta os macro-processos em uma visão que permite compreender em um olhar de alto nível sobre tudo o que é feito na organização e como as principais atividades de negócio estão integradas.

A representação visual da visão estratégica comumente segue algum modelo de classificação de processos como:

  • Process Classification Framework (AQPC PCF®)
    Classifica os processos em duas categorias:
    » Processos Operacionais
    » Processos Gerenciais e de Suporte.
  • Value-Added Chain (VAC) de Michael Porter
    A Cadeia de Valor Agregado, proposta por Michael Porter, classifica os processos originalmente em 2 categorias:
    » Processos Primários (ou Finalísticos)
    » Processos de Apoio (ou Secundários ou de Suporte)
    Versões mais modernas da cadeia de valor propõem uma terceira classe de processos para visualizar os Processos de Gerenciamento.
  • Value Reference Model Framework (Value Chain VRM)
    Apresenta um framework inspirado na Cadeia de Valor de Porter porém em um desdobramento que pode chegar a cinco níveis. No nível 1 (estratégico) as atividades são classificadas entre:
    » Planejamento
    » Governança
    » Execução.

Todos estes modelos têm uma coisa em comum – buscam representar no seu nível mais elevado de abstração uma visão na qual a organização possa identificar sob qual macro-atividade um processo, atividade de trabalho ou tarefa operacional é realizada, à medida que desdobramos cada macro-processo nos níveis a seguir.

Nas organizações brasileiras, tem sido mais comum ver o mapeamento de nível estratégico implementado no modelo de Cadeia de Valor Agregado e o Process Classification Framework da AQPC.

Em termos de notação gráfica, é comum ver este nível representado graficamente por Diagrama VAC (Cadeia de Valor Agregado) ou fluxograma.

Visão Gerencial | Processos de Negócio

A visão gerencial é estabelecida pelo mapeamento do fluxo do Processo de Negócio  olhando e compreendendo uma determinada atividade do negócio de ponta a ponta.

Cada macro-atividade do nível estratégico é mapeado visualizando suas principais etapas, que podem muito bem se desdobrar em outros Processos de Negócio ou em Processos de Trabalho (workflow). Isto dependerá da complexidade do negócio representado. Enquanto alguns processos de negócio podem ser facilmente descritos numa combinação de uns poucos fluxos de trabalho, outros são muito mais complexos e envolvem a combinação de processos.

Nesta visão, ainda é mais importante entender quais as atividades de negócio são realizadas e como estão interligadas, do que propriamente quem é responsável pela sua execução.

Em termos de notação gráfica, as organizações variam na adoção entre Diagrama VAC (Cadeia de Valor Agregado), Diagrama EPC, fluxograma ou Diagrama BPMN de Orquestração de Processo.

Visão Tática | Processos de Trabalho

A Visão Tática em uma arquitetura de processos busca representar o detalhamento do Processo de Trabalho (fluxo de trabalho, ou workflow), que em geral é uma atividade de um Processo de Negócio modelado no nível da visão gerencial.

Neste nível, a modelagem do processo geralmente explicita o quê é o trabalho realizado para cumprir aquela etapa do processo de negócio: quais são as atividades, quem são seus responsáveis, como é a sua ordem de precedência, que diferentes sequências de atividades podem existir de acordo com alguma condição do negócio, em um modelo que representa a lógica sequencial do trabalho realizado.

Um fluxo de trabalho modelado na visão tática também pode ser detalhado em subprocessos para abstrair pontos de complexidade, ou quando o processo é longo e complexo.

As notações de modelagem de processos mais utilizadas para representar graficamente um fluxo de processo de trabalho é o BPMN, o fluxograma e o EPC.
O BPMN tem se mostrado a notação mais adotada pelo benefício de possibilitar que um fluxo de trabalho mapeado pelo negócio possa, com poucas adaptações, ser automatizado em uma plataforma BPMS.

Visão Operacional  | Processos/Procedimentos Operacionais

Dependendo da necessidade de formalização e detalhamento da execução de uma ou mais atividades de um processo de trabalho, é possível que algumas organizações cheguem ao detalhamento da visão operacional.

Neste nível, uma atividade de um processo de trabalho é detalhada de forma a explicitar como o trabalho é feito: quais ferramentas são usadas, qual o passo a passo realizado para executar a operação, quais as práticas adotadas pelo profissional que executa a tarefa, quais os prazos e custos estimados e realizados.

A visão operacional também pode ser representada graficamente através de diagramas em BPMN ou fluxograma mas é mais comum que sejam formalizados como documentação complementar – por exemplo através de POP (Procedimentos Operacionais Padrão).

A visão operacional tem sido uma das fontes de identificação de oportunidades de automatização através da robotização de tarefas (Robotic Process Automation – RPA).

Até que nível de representação da Arquitetura de Processos eu devo ir?

A grande questão em torno da Arquitetura de Processos é o entendimento equivocado de que ela só estará completa quando todas as atividades, tarefas e processos estiverem mapeadas e detalhadas nos diversos níveis listados acima.

Este é um trabalho árduo, que consome muito tempo da organização e que dificilmente traz resultados satisfatórios.

Enquanto o modelo representado na Visão Estratégica (Corporativa) e Gerencial (Processos de Negócio) tendem a ser estáveis por algum tempo na vida a organização, o Nível Tático (Processo de Trabalho) pode sofrer revisões com maior frequência, e as definições em Nível Operacional ocorrem muitas vezes organicamente, no dia a dia da organização, às vezes sem mesmo chegar ao conhecimento da liderança executiva.

As mudanças no nível estratégico ou gerencial acontecem com menos frequência pois ocorrem em situações como quando a organização passa a oferecer um novo produto/serviço ou realiza uma mudança em nível estrutural (como uma fusão, venda de parte do negócio ou aquisição do negócio de uma outra empresa).

Já as mudanças no Nível Tático acontecem em virtude das ações estratégias adotadas pela organização ou necessidades provenientes de urgências operacionais (por exemplo: a mudança de uma legislação que necessita que o fluxo de trabalho realizado seja readequado para atender aos requisitos da lei).

E no Nível Operacional, as alterações são ainda mais frequentes, pois ele reflete as adaptações da operação à constante busca por um pouco mais de ganho de eficiência operacional – por exemplo: a troca de ordem na sequência de passos, paralelismo de ações ou a substituição de um formulário de papel por um formulário eletrônico já impactam as definições de um processo operacional.

Portanto, há ganhos muito mais significativos para a organização em conhecer e estruturar os níveis Estratégico e Gerencial, podendo em alguns casos avaliar a necessidade do detalhamento do nível Tático e em casos muito específicos (como a necessidade de material que viabilize treinamento de uma equipe com alta rotatividade ou por regulações como as requeridas nos negócios relacionados a saúde e segurança) o detalhamento de atividades específicas no nível operacional.

Assim, nossa recomendação é:

  • Elabore e mantenha a arquitetura da Visão Estratégica e Gerencial (Processos de Negócio) para consolidar o entendimento do negócio realizado pela organização e guiar projetos de transformação de processos.
  • Priorize quais Processos de Negócio valem a pena serem detalhados em Fluxos de Trabalho para o Nível Tático, considerando os mais relevantes para análise, redesenho e transformação.
  • Seja bastante criterioso sobre a real necessidade de detalhar o nível operacional, selecionando as atividades na qual esse detalhamento seja de fato necessário, e neste caso defina responsabilidades para mantê-lo atualizado.

Foco NO Cliente ou Foco DO Cliente: o que sua empresa está praticando?

Muito falamos aqui neste blog de BPM, metodologias, filosofias, técnicas e notações que utilizamos para otimizar os processos de nossas organizações, com o objetivo de gerar maior valor para os clientes.

Mas é importante lembrar que nós mesmos, praticantes ou interessados em BPM, também somos clientes no nosso dia a dia. Somos clientes de empresa de telefonia, banda larga, TV por assinatura, serviço de streaming, e por aí vai.

Basta nos colocarmos no papel de cliente, que logo vem a mente vários exemplos de coisas que não gostamos ou que gostaríamos que fossem diferentes nas empresas que prestam serviços para nós. Vejamos alguns exemplos dos chamados “momentos da verdade”, que são os momentos em que um cliente entra em contato com a organização, que na verdade se trata do contato sempre com um processo desta organização:

  • Eu quero contratar apenas internet banda larga para minha casa, mas a operadora empurra junto uma linha de telefonia fixa, mesmo que eu não utilize.
  • Eu gosto muito de uma série específica e de alguns canais de documentários, mas hoje não disponho de um pacote de TV por assinatura que me permita escolher apenas estas opções. Assim, sou obrigado a contratar um plano mais completo (e mais caro) com dezenas de canais que nunca vou assistir.
  • Eu gostaria de marcar e agendar uma consulta num posto de saúde pela internet, e não precisar ter que chegar as 04:00 da manhã para pegar uma senha para atendimento.
  • Eu ligo para o 0800 de algum prestador de serviço, mas sou obrigado a repetir todo o meu problema a cada vez que sou encaminhado para um atendente diferente.

Por que isso acontece? Porque as organizações (sejam públicas ou privadas) estão praticando o “Foco no Cliente” (atenção à preposição!), ou seja: tentam projetar ou inferir aquilo que acreditam que o cliente está buscando, ou mesmo ignoram a experiência do cliente, por conta de alguma característica ou restrição interna da organização. Algumas características básicas da abordagem com foco no cliente:

  • Geralmente baseado na Cadeia de Valor da organização, onde a empresa projeta o que o cliente deseja.
  • O cliente se adapta e escolhe o que as empresas oferecem, na forma como oferecem. Ou seja, não existe muita customização ou adaptação às necessidades específicas de cada cliente.

Vejamos outro exemplo para diferenciar o foco no cliente e o foco do cliente.

Uma rede de varejo com uma variada adega de vinhos, que oferta produtos em diferentes faixas de preço, entendeu que seria uma boa ideia possibilitar aos consumidores  interessados em alguns produtos de linha superior, experimentarem a bebida para avaliarem se o valor é justo pela qualidade da bebida.

É claro que abrir uma garrafa de um vinho caro para oferecer uma prova a qualquer pessoa que se diga interessada não é uma boa estratégia, até porque sabemos que o vinho não mantém suas características por muito tempo depois da garrafa aberta.

Então, a solução pensada foi de oferecer porções de degustação dos principais rótulos, por um custo acessível e de valor agregado para um bom conhecedor de vinho. Para isso, disponibilizaram um equipamento específico que permite servir porções mantendo o vinho da garrafa aberta sob condições de ambiente que permitam mantê-lo aberto por algum tempo sem perder suas características.

Pensando sob este ponto de vista, parece uma excelente estratégia para aproximar o cliente do produto e conduzi-lo para uma possível venda, sem perder o valor agregado do produto.

Desta forma, definiram a seguinte jornada para o cliente obter a taça de degustação:

Perceba que o processo exige que o cliente (que deseja apenas tomar uma taça de vinho!) passe por uma grande quantidade de etapas para realizar este desejo: entrar em várias filas, realizar cadastros, realizar crédito, etc. A burocracia envolvida certamente desestimularia aquele cliente eventual que teria interesse em utilizar máquina, mas desistiria ao saber de todos os passos que são necessários. E quem sabe ele seria o cliente que levaria aquela garrafa de vinho top!

Neste momento podemos fazer um questionamento: este processo está errado?

Conceitualmente e semanticamente o processo está correto, e possivelmente exista um racional justificando cada uma daquelas etapas. Pode ser, por exemplo, que a organização deseja cadastrar e fidelizar o cliente. Ou queira gerar uma base de dados de clientes para mail marketing e promoções. Mas mesmo que o racional utilizado para modelar todas estas etapas no processo seja justificável, o fato é que do ponto de vista do cliente, este processo é ruim e burocrático!

Então como seria este mesmo processo, modelado com foco do cliente? Vejamos:

Percebam a diferença! O que acontece é que neste caso estamos praticando o foco do cliente, ou seja, o processo é baseado nas expectativas do cliente, com a empresa se colocando no lugar do mesmo.

No foco do cliente, os objetivos são:

  • Avaliar apenas o que realmente importa para o cliente, eliminando etapas que não agregam valor ou não são necessárias do ponto de vista do cliente.
  • Reduzir o número de interações, ou seja, a quantidade de vezes que o processo (a organização) precisa se comunicar ou solicitar algo para o cliente.
  • A percepção do cliente se torna a referência sobre a efetividade ou não do processo. Se, por exemplo, meu processo está gerando muitas reclamações no “Reclame Aqui” ou no Procon, isto significa que o processo não está bem, mesmo que atenda a indicadores internos ou benchmarks disponíveis.
  • Melhorar a satisfação do cliente.

Veja que a abordagem do foco do cliente parte de uma premissa bem simples: entender como o cliente vê que sua necessidade deveria ser atendida e estruturar o processo sob a ótica dele. Mas é claro que nem sempre é tão fácil, podem existir fatores que impedem uma transição completa, como por exemplo:

  • O cliente pode não estar disponível para participar do desenho, que é comum no caso de órgãos públicos onde o cliente é o cidadão, ou empresas que oferecem serviços ao grande público. Certamente existem técnicas que permitem captar o feedback do cliente nestes casos (Canal para envio de sugestões/reclamações, Pesquisas de opinião, etc), mas não costuma ser tão efetivo quanto você ter o cliente contribuindo presencialmente.
  • A empresa pode ser regida por regulações e normas que exigem um certo grau de burocratização (Ex: Sarbanes-Oxley), que pode ser visto como desnecessário para o cliente, mas é importante para fins de auditoria e conformidade da organização.

Acreditamos que é importante tentar mudar o paradigma e passar a adotar, sempre que possível, o foco do cliente no desenho dos processos. Mesmo que não seja viável adotar completamente esta abordagem, apenas o exercício de se colocar no lugar do cliente, experimentando o processo, já fornece uma visibilidade muito boa de como vai ser a interação do cliente com os processos, permitindo inclusive antecipar e tratar possíveis problemas.

Diagramas BPMN com ou sem raias: 3 abordagens em que o foco da modelagem faz a diferença

Usar ou não usar pools e lanes (piscinas e raias) na modelagem de processos é uma discussão de longa data e persistente ainda nos dias de hoje.

A especificação da notação BPMN apresenta e explica a utilização destes componentes mas declara que o seu uso é opcional, o que dificulta ainda mais o entendimento por algumas equipes sobre quando e como usá-los.

Modelar com swimlanes pode trazer clareza visual sobre as entidades organizacionais envolvidas no processo, porém tende a deixar o diagrama mais carregado visualmente, já que haverá mais linhas para se cruzarem e em alguns casos conectores mais longos para unir atividades em raias distantes.

Não utilizar swimlanes, por outro lado, permite aproximar as atividades e elementos do fluxo criando um diagrama teoricamente mais enxuto, mas torna implícito a identificação das áreas e papéis resolvidos – o que até poderia ser resolvido por outros artifícios como o uso de anotações ou complementação na descrição das tarefas (forçando a ter caixas maiores para cada elemento do fluxo e igualmente carregando visualmente o diagrama do processo).

Entre os prós e contras de cada abordagem, há um aspecto muito mais relevante a ser considerado: para quê o modelo de processo está sendo criado.

Exploramos aqui três focos de modelagem que podem ajudá-lo nessa avaliação.

Para ilustrar cada abordagem, vamos utilizar como exemplo um fluxo inspirado no clássico processo de tele-entrega de pizza, traduzido livremente do modelo “5.2 The Pizza Collaboration” em BPMN 2.0 by Example (já usamos este exemplo em um outro artigo sobre modelagem de processos no blog da iProcess – aqui).

1. Quando o foco é analisar como as atividades adicionam valor ao processo 

Neste caso, a melhor abordagem de modelagem pode ser sem lanes, desenhando o processo como um fluxo linear em que todas as atividades essenciais estão em uma mesma linha, e tudo o que é contorno/alternativa é mapeado para cima ou para baixo do fluxo.

Esta é uma abordagem de uso da notação BPMN inspirada em Lean, no qual o Value Stream Mapping (VSM) busca mapear o fluxo de adição de valor do processo.

Esta abordagem foca na fluidez das atividades essenciais à produção do resultado do processo, que são as que devem ser priorizadas em ações de melhoria do processo visando a sua otimização.

 

2. Quando o foco é compreender as responsabilidades dos envolvidos na execução do processo

Aplicar a abordagem de raias para representar os papéis envolvidos no processo é interessante para deixar mais claro visualmente as responsabilidades de cada participante.

Isto possibilita identificar que atividades são executadas por cada papel, e a partir disso identificar quais são as habilidades, competências e nível de autoridade requerido na execução de cada etapa do trabalho.

 

3. Quando o foco é tornar explícitas as interações do cliente com a organização através do processo 

Neste caso, o uso de pools e lanes traz uma camada de informação visual adicional importante, que é a da comunicação entre o processo da organização e o processo do cliente. É possível não apenas identificar onde estão os “momentos da verdade” em que o cliente interage com a organização, mas também com quem e por quê ele faz essas interações.

Esta abordagem é ideal em projetos de transformação que têm como objetivo alinhar o negócio ao foco do cliente, possibilitando compreender a sua experiência atual.

 

Todas essas abordagens são possíveis dentro da utilização da notação BPMN conforme as suas regras – portanto não existe certo e errado.

O melhor caminho é, em primeiro lugar, ter claro qual o propósito da modelagem que estamos realizando e então definir a melhor estratégia de uso da notação!


Problemas comuns na modelagem de processos em BPMN III – Uso de tarefas para sinalizar o resultado de gateways

Continuando a série sobre problemas comuns na modelagem de processos em BPMN (veja os artigos anteriores aqui e aqui), hoje iremos falar de uma situação bastante recorrente que constatamos nos nossos treinamentos, que é o uso de tarefas para sinalizar o resultado de gateways no processo.

Para explicar melhor o que queremos dizer, veja o exemplo abaixo:

Perceba que a pessoa que modelou o processo, para demonstrar os resultados do gateway relativo à atividade “Avaliar Reembolso”, optou por criar duas tarefas em cada um dos fluxos de sequencia ligados ao gateway, nomeando-as como “Aprovado” e “Reprovado”.

O elemento Tarefa (Task) de BPMN se refere a um trabalho que é efetivamente realizado dentro de um processo. Uma tarefa deve, essencialmente, indicar uma ação a ser realizada, que consuma algum recurso (como a tarefa “Avaliar Reembolso” no exemplo acima).

Logo, concluímos que não faz sentido utilizar uma tarefa apenas para indicar uma mudança de status ou sinalizar os resultados de um gateway.

Qual então seria a forma correta de modelar este caso? Veja no exemplo atualizado abaixo:

A abordagem correta (e mais simples!) é simplesmente nomear os fluxos de sequencia ligados ao gateway. No caso acima, cada fluxo de sequência foi nomeado com os resultados possíveis da tarefa de Avaliar reembolso, ou seja, “Aprovado” ou “Reprovado”.

Com isto, o desenho do processo fica mais limpo e fácil de interpretar. Simples e prático! :-)

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! ;-)