Encontre a turma de BPM e SOA na rede

Business Process Management (BPM) e Service Oriented Architecture (SOA) são temas de discussões em diversos canais de redes sociais.

Facilitamos a sua vida reunindo aqui links para algumas destas comunidades virtuais:

BPM Forum

É o principal forum de BPM no Brasil, com mais de 1700 inscritos. Abrange desde tópicos altamente voltados à filosofia BPM aplicada aos negócios até questões relacionadas a tecnologia:

AN.br

Esse fórum é de Analistas de Negócios, mas eventualmente são levantadas questões relacionadas a BPM:

Grupos no Linkedin

Grupos no Facebook

FreeBPM

Fórum brasileiro sobre plataformas livres de BPM:

Sites

 

E é claro, você pode acompanhar atualizações de conteúdo da iProcess através dos seguintes canais:

Respondendo a dúvidas: como representar email, planilha ou sistema em BPMN?

Frequentemente, em cursos e consultorias, nos deparamos com questões como a abaixo, encaminhada por um de nossos leitores:

“Estou modelando processos e a determinação que recebemos é sempre usar na atividade o ícone que representa o tipo de tarefa.
Há dúvidas e opiniões diferentes em o que aplicar quando:
- E-mail escrito e enviado por uma pessoa.
- Uso de planilha Excel ou outras ferramentas que não são aplicação do negócio
- Utilização de ferramentas externas como site de banco, ou sistema cuja administração é exclusiva do fornecedor.
Como recomendam a representação desses itens?”

Na verdade não existem elementos no BPMN para representar especificamente estes itens, porque o objetivo da notação é disponibilizar componentes para a representação da sequência lógica da execução de um processo, e não os meios utilizados. Quando representamos uma tarefa em um processo, indicamos que ali acontece uma ação, um trabalho que precisa ser realizado para que o processo siga adiante no fluxo. Planilhas, software, sites, documentos e emails são meios através do qual as tarefas podem ser realizadas – mas não o trabalho em si.

A notação permite representar entradas e saídas de informações através do elemento “data object” ou “message”. Entretanto, eles são apenas elementos acessórios no diagrama e não especificam o tipo de tecnologia usada (planilha, documento, formulário, email, telefonema…). Assim, se para a análise do processo é muito relevante apontar visualmente que meios são usados em uma atividade, utilize este elemento e use sua descrição para esclarecer se é um documento, um formulário ou planilha.

Neste exemplo de processo com implantação manual, alguns exemplos de "meios" como planilhas e formulários representados junto ao processo. Tanto o formulário TR3 quanto o TR3.1 são formulários que transitam entre tarefas (sai de uma e vai para a outra), embora esteja associado implicitamente através do que chamamos "visual shortcut". A planilha de controle de estoque é consultada e eventualmente atualizada durante a tarefa "Verificar estoque". Nesta perspectiva, o email que comunica o solicitante sobre a falta de itens seria produzido na tarefa "Verificar estoque", e provavelmente documentado como um dos procedimentos a serem realizados durante esta tarefa no caso de faltarem itens.

Em relação ao envio de emails, esta é em geral uma questão bastante controversa, e a sua representação depende da perspectiva sob a qual o processo está mapeado. O fato é que é diferente mapear um processo de negócio para análise e documentação ou para execução por um BPMS.

Quando mapeamos um processo de análise e documentação, representamos o processo de negócio sob a perspectiva das pessoas que realizarão o trabalho. Em geral, o envio do email é parte do trabalho de uma tarefa, como por exemplo avaliar alguma coisa (e um dos procedimentos da tarefa é enviar um email notificando a parte interessada). Assim, o envio do email não é representado no fluxo, mas é descrito como um procedimento da atividade.

Em um processo que está sendo mapeado para ser automatizado, a perspectiva muda discretamente. Ela tem a ótica do BPMS, o motor de processos – que é quem realmente executará a atividade do envio do email. Nestes casos, não há uma atividade humana em si. O envio será realizado pelo sistema, automaticamente, e alguém receberá a mensagem (mas nem sempre fará algo com ela – muitas vezes é apenas uma notificação do estado do processo). Para estes casos, costumamos representá-la através de uma atividade de serviço, já que é um serviço de email que será acionado para enviar a informação. Esta tarefa de serviço acaba sendo posicionada na lane da pessoa que receberá a mensagem, e muitas vezes as nomeamos como uma tarefa passiva como “Receber aviso de aprovação”. Para esta situação, muitas ferramentas de automatização de processos customizaram ou estenderam a notação, criando elementos específicos para representar este tipo de atividade (o que é permitido pela especificação BPMN 2.0).

Este exemplo representa um processo mapeado sob a perspectiva da automação, em que o processo será executado e controlado através de um BPMS. O envio do email para o solicitante é enviado automaticamente pelo sistema, a exemplo da sugestão de uso da notação acima para este cenário.

Vale lembrar que as dicas acima não são exatamente definições da notação  (pois a especificação BPMN não entra neste mérito), mas algo que consideramos boas práticas para utilizá-la corretamente.

BPMN: Modelando processos de negócio com elementos avançados (Parte IV)

Neste quarto e último artigo da série “BPMN: Modelando processos de negócio com elementos avançados”, abordaremos de forma especial o subprocesso de eventos, levando em conta as definições de notação.

Subprocesso Eventual (Event-Subprocess)

O subprocesso eventual é parte opcional do processo e é utilizado para tratar com eventos excepcionais que ocorrem no processo pai.

Subprocessos eventuais são acionados pela ocorrência de um evento previsto durante a execução do processo principal. Assemelham-se a outros tipos de subprocessos contidos dentro de um processo pai (e não são reutilizáveis), mas dintinguem-se de outros subprocessos, pois não são ligados ao  fluxo de sequência do processo principal, uma vez que só serão iniciados quando a trigger do evento de início for acionada.

O Subprocesso eventual é representado graficamente por um retângulo com bordas arredondadas e linha tracejada. Na forma contraída, apresenta um símbolo [+] na base inferior implicando no entendimento que esta atividade contém um conjunto de tarefas. Também pode ser representado na forma expandida, demostrando assim seu fluxo no processo pai.

Subprocesso eventual (ou subprocesso de eventos) - Representado pela imagem da esquerda na forma contraída e na imagem a direita na forma expandida.

Um subprocesso de eventos pode ter somente um evento de início e este evento deverá ser necessariamente disparado por algum fato específico que gere seu início (catch). Em outra palavras, o subprocesso eventual não pode ser representado pelo evento de início “none”.

Este fato específico (que gera o início do subprocesso de evento) pode significar as mais diferentes informações. Vejamos as mais comuns:

  • Um fato temporal: uma data (Ex. 01 de março) – Simbolizado por um relógio.

  • Por uma mensagem: Com a chegada de uma informação (Ex. Um documento, um e-mail, um telefonema) – Simbolizado pelo envelope branco.

  • Uma condição: Ex. Estoque menor que 10 unidades – Simbolizado por formulário.

  • Um sinal: Quando algo estiver errado (Ex. Sistema do cumprimento do pedido não respondido) – Simbolizado por um triângulo vazado.

Para mais informações sobre eventos confira os artigos Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim e Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários.

Event-Subprocess Interrupting e Event-Subprocess Non-Interrupting

Falando um pouco mais sobre o evento de início de um subprocesso eventual, apontamos dois tipos que definem qual o impacto que o subprocesso causará no processo pai. São eles:

Event-Subprocess Interrupting – Evento que interrompe o fluxo do processo principal (pai). Representado por um círculo com linha contínua.

Event-Subprocess Non-Interrupting – Evento que não interrompe o fluxo do processo pai. O processo ocorre em paralelo. Representado por um círculo com linha tracejada.

O exemplo a seguir demonstra o uso de subprocessos eventuais, em um processo muito comum de “Pedido de Reservas”, envolvendo reservas de voo e hotel.

Durante a execução deste processo, podem ocorrer o disparo de qualquer um dos dois subprocessos eventuais:

1 – Pode ocorrer o cancelamento do processo de reservas, interrompendo o processo de negócio e com isso finalizando a solicitação de reservas. Veja que o evento que inicializa o subprocesso eventual de cancelamento é representado graficamente com uma borda de linha contínua (Event-Subprocess Interrupting). Isso significa que ele interromperá a execução do processo principal, e executará este subprocesso.

Event-Subprocess Interrupting

2- Caso o processo não seja cancelado, o cliente pode enviar um pedido de “Status”, retornando a informação da situação do pedido das reservas. Como o evento que inicializa este subprocesso é representado com uma borda com linha tracejada (Event-Subprocess Non-Interrupting), o processo principal não é interrompido, com isso subprocesso eventual é executado em paralelo ao processo principal, fazendo com que o pedido de status seja atendido paralelamente às atividades do processo pai.

Event-Subprocess Non-Interrupting

 

Importante:
- O subprocesso eventual non-interrupting pode ser executado várias vezes durante a execução de um processo, e pode ter várias instâncias em execução em paralelo.

- Uma vez que o processo principal tenha sido concluído, mesmo que o fato gerador do evento ocorra, o subprocesso eventual não será acionado, pois seu ciclo de vida depende do processo principal. Por exemplo, o cliente solicita o pedido de status do pedido porém o processo principal já foi finalizado, este pedido não será processado.


Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:

Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

Recentemente um de nossos leitores nos escreveu sobre seu entusiasmo em iniciar uma experiência prática em BPM. Ele compartilhou conosco um desenho de processo (que discutiremos neste artigo, com a permissão do leitor) cujo objetivo era ser automatizado com dois propósitos: servir como base para a monografia e também validar o BPMS como tecnologia para automatizar processos na empresa de varejo no qual atua na área de TI.

O argumento da escolha do Processo de Pré-venda para esta primeira experiência foi: que fosse pequeno (poucas atividades) para viabilizar a automação no curto tempo para a monografia, mas que ao ser desenvolvido seria usado como piloto para provar a tecnologia na empresa e, dando certo, o processo evoluiria para as etapas seguintes da venda. Portanto, havia uma expectativa de que a automatização dele pudesse demonstrar bons resultados para a organização, a ponto de convencê-los que valeria a pena investir na adoção da solução e a implementação do restante do processo (e eventualmente de expandir a iniciativa para todos os processos da organização).

Embora ter processos executados e controlados por um BPMS (ou um motor de workflow) possa ser parte do ciclo da gestão por processos, não significa que a empresa tenha adotado Business Process Management como filosofia de gestão. Mas, dependendo do contexto organizacional, muitas vezes a iniciativa nasce dentro da TI, em situações como esta.

A questão é: seria este um bom processo para demonstrar resultados iniciais que possam alavancar uma iniciativa maior BPM (e em uma monografia, apresentar resultados satisfatórios)?

É aqui que este artigo realmente começa :-)

A notação BPMN é excelente para representar atividades de um processo de negócio. Mas a especificação não esclarece exatamente o que é o escopo de um processo de negócio, e nem o nível de granularidade, ou mesmo um método de uso. Apenas dispõe os elementos e as regras de uso visando uma padronização no entendimento de um processo mapeado.

Analisamos juntos o processo e percebemos que este diagrama não é um processo de negócio. É apenas uma parte dele, praticamente o fluxo de ações de uma atividade.

Os benefícios típicos da automatização aparecem quando o processo de negócio :
- Envolve mais de uma área da empresa (melhoria da comunicação)
- Permite extrair indicadores que demonstrem o desempenho do processo (melhoria do controle)
- Deve ser controlado para que sua execução siga integralmente o fluxo modelado
-Possibilita  apresentar informações de tempo do processo que possam apoiar as decisões que levarão à sua evolução (quanto tempo o processo leva hoje e quais atividades devem sofrer alguma melhoria para que esse tempo possa ser reduzido).
[Veja mais sobre benefícios típicos da automação de processos no artigo de Paulo Capiotti, Benefícios da Automação de Processos]

Ao analisar o diagrama, desaconselhamos a sua automatização, pois a mesma não obterá nenhum benefício significativo. Justificamos isto apontando alguns argumentos que usamos quando estamos avaliando a viabilidade/ganho ao se automatizar um processo para um cliente:

I. Este processo tem apenas um usuário. No diagrama original há duas lanes, a do vendedor e a do cliente, mas o fato é que o único a interagir diretamente com a interface humana do BPMS, neste caso, será o vendedor. Se ajustarmos o diagrama para representar apenas as atividades que serão automatizadas (conforme abaixo) e colocando o cliente em uma outra pool (já que ele não irá interagir diretamente com o BPMS) isto se torna bastante visível:

II. Todos estes passos acontecem em um curto espaço de tempo. Pelas tarefas mapeadas, percebe-se que elas ocorrem com o cliente ali, na frente do vendedor. Neste caso, ao automatizar cada uma destas tarefas separadamente, poderá gerar um impacto negativo no aspecto da interface, porque para cada “passo” o usuário (vendedor) terá que: procurar a tarefa na lista de trabalho, clicar para abrir, realizar as ações necessárias na tela, finalizar a tarefa (para que o BPMS registre que aquela tarefa foi concluída e verifique qual a nova tarefa, criando um novo item na lista de trabalho), aguardar o refresh da lista de trabalho e então realizar novamente estes passos para cada uma das atividades do fluxo. Em termos de usabilidade, isso se torna desgastante para o usuário porque faz com que ele tenha que dar inúmeros cliques para fazer uma sequência de ações que possivelmente poderia ser condensada em uma única tela. Em outras palavras, esta sequência de ações poderia compor um Caso de Uso (artefato típido da análise de sistemas tradicional).

III. Além disso, se este processo já é executado manualmente, possivelmente há alguma flexibilização na ordem em que estas tarefas ocorrem (por exemplo, em algum caso o vendedor poderia verificar o cadastro do cliente antes de incluir os itens de compra). É importante considerar isso, pois ao automatizar o fluxo no BPMS, ele sempre será executado como foi modelado. Isso implica que nada pode ser feito antes nem depois do previsto – tudo tem que seguir a ordem das tarefas no diagrama. O que é tradicionalmente um benefício da automatização de processos (garantia da integridade da execução), neste caso poderia ser um aspecto negativo, pois não é o engessamento das etapas que queremos (e toda vez que algo precisar ser levemente diferente os usuários dirão que não é possível porque “o sistema não permite”).

Então percebemos que o processo escolhido é, na verdade, apenas uma atividade de um processo de negócio muito maior.

Fica fácil nesta análise perceber que o sucesso de projetos pilotos para a adoção de um sistema de gestão de processos não depende apenas da qualidade do produto, mas também da escolha de um processo com tarefas que possam efetivamente demonstrar bons resultados.

Ao leitor, sugerimos ampliar um pouco mais a abrangência do processo – o que não significa necessariamente que será mais trabalho. Para um piloto como este, recomendamos mapear, em um nivel macro, todo o processo (não apenas esta etapa da pré-venda), e como primeiro esforço de automação identificar pontos de controle que poderiam ser automatizados (seis ou sete tarefas onde o processo muda de status ou há alguma alteração na rota do fluxo).

Alguns desses pontos de controle podem até ser obtidos de sistemas que já existem hoje na empresa, o que demonstraria ainda mais benefícios na automatização do processo. Por exemplo, no sistema que controla os pedidos, fazer com que o processo siga adiante quando a entrega for despachada. Poderia ser agregado ao processo uma tarefa de serviço para buscar essa informação no sistema.

Com um piloto assim, os indicadores podem demonstrar informações muito mais significativas para a organização do que conhecer, por exemplo, quantos minutos está levando a pré-venda. Será possível identificar onde ocorrem os gargalos, que estapas são críticas e estão atrasando o processo, possivelmente até instigar a empresa em investir na análise,  melhoria e medições mais abrangentes, e quiçá em adotar por completo uma filosofia de gestão por processos.