Webinar – O que a automatização pode fazer pelos seus processos de negócio?

Neste webinar, apresentado por Eduardo Britto em 12/08/16, compartilhamos nosso expertise e experiência sobre benefícios que podem ser obtidos no gerenciamento de processos de negócio com a utilização de soluções de tecnologia.

Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

Os slides utilizados na apresentação também estão disponíveis no SlideShare:
http://www.slideshare.net/iProcessBPMeSOA/webinar-iprocess-o-que-a-automao-pode-fazer-por-seus-processos

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Qual a diferença entre BPMS e workflow?

Resposta: Workflow é um dos conceitos de tecnologia para processos mais antigos, com mais de 30 anos de uso no mercado. É a tecnologia que propicia o controle de fluxos de trabalho de forma automatizada, gerenciando a execução sequenciada de tarefas executadas por pessoas e por sistemas. Com o amadurecimento da disciplina de gestão por processos de negócio, novas tecnologias foram agregadas ao simples gerenciamento de tarefas. Assim, uma suíte BPM (ou BPMS) é uma ferramenta mais completa, que também incorpora um motor de processos (workflow) incorporando outros componentes como: modelador gráfico de processos, gerenciamento de regras de negócio, gerenciamento de interação com outros sistemas e pessoas, recursos de gestão proativa do processo entre outros.
Sugerimos a leitura do artigo abaixo, que fala mais sobre o tema:
BPM e Workflow – qual a diferença? 

 

Qual a ferramenta usada para os exemplos de automação?

Resposta: A iProcess trabalha hoje com diversos BPMS, tais como Oracle BPM, Lecom BPMS, Sydle, Orquestra, BizAgi e Oracle PCS. As telas dos exemplos da apresentação forem retiradas de alguns destes produtos.

 

Qual a ferramenta sugerida  para simulação?

Resposta: Existe diferentes produtos pagos no mercado que permitem a realização de simulação de processos. Contudo, o mais conhecido e que sugerimos que seja avaliado numa primeira iniciativa é a funcionalidade de simulação do BizAgi, por ser um software hoje gratuíto, acessível para a maioria das pessoas, e que possui bons recursos de simulação. Vocês podem conhecer um pouco mais do simulador do BizAgi no Webinar Simulação como Ferramento de Análise de Processos de Negócio.

Webinar – Erros & Acertos do uso de BPMS no Brasil

Esta é a gravação do primeiro Webinar da série lançada este ano pela iProcess, através do qual compartilhamos nosso expertise e experiência em gestão por processos.
Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

 

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Assisti a uma palestra há algumas semanas onde a abordagem quanto ao termo de automação foi questionado, ou seja, a tendência é não utilizarmos mais o termo devido às plataformas atuais: celular, sistemas legados, workflow etc. Qual a sua opinião sobre essa colocação, um pouco superficial, mas que preocupa?

Resposta: De parte da iProcess, não nos preocupa se o termo a ser utilizado é automação, automatização, digitalização, … e sim que possamos viabilizar a melhoria de processos através da tecnologia. 

Como saber qual é a melhor área para fazer um protótipo de modelagem?

Resposta: Certamente a escolha do prirmeiro processo a ser modelado ou redesenhado na organização é muito importante para o sucesso da continuidade destas iniciativas. Convido a vocês a assistirem a um webinar em que falamos do assunto: Webinares iProcess 2014 – Primeiros Passos em BPM: Os desafios do primeiro projeto e Webinares iProcess 2014 – Primeiros Passos em BPM: da Venda Interna ao Primeiro Processo.

A base de automação é via BPA?

Resposta: O BPA é uma solução para a modelagem de processos pelo escritório de processos onde são armazenados os processos na visão de negócio. A partir desta visão o processo precisa ser detalhado para um modelo orientado à automação para que possa ser implementado em uma ferramenta de BPMS.

Eduardo, você tem como demonstrar um contexto referente ao item 11? De fato, esse é um problema quando você apresenta uma solução para o cliente?

Resposta: O item “#11 Achar que o processo irá substituir as aplicações” traz uma situação muito comum nas organizações de acreditarem que o BPMS compete com o sistema legado. A grande confusão acontece quando pensamos no BPMS substituindo pequenos formulários e cadastros que existem em sistemas periféricos, pois esta substituição pode até se mostrar viável tecnicamente. Contudo, quando falamos de sistemas mais robustos, como um sistema de RH, financeiro, de planejamento da produção, … normalmente fica mais claro para o cliente que o BPMS tem o objetivo de orquestrar a tramitação dos processos e não de substituir funcionalidades como a emissão de uma nota fiscal ou o cálculo de uma folha de pagamento.

Existe alguma ferramenta que permita modelar o processo e os DADOS que fluem no processo?

Resposta: Todas as ferramentas de automação trabalham com o conceito de modelar o processo e, ao mesmo tempo, modelar os dados que vão trafegar no processo. O que difere uma da outra é a forma como esta modelagem é feita. Algumas tem a parte de modelagem de dados bastante explícita e separada de outras etapas do processo de desenvolvimento (praticamente a definição de tabelas de dados relacionadas ao processo), já em outras esta associação é mais sutil, onde são definidos objetos simples de dados.

O mapeamento dos processos são utilizados pelo sistema de automação? Percebi que todos os desenhos foram feitos no Bizagi, tendo os processos no visio é fácil fazer essa conversão?

Resposta: Sim, a base inicial em toda ferramenta de automação de processos é ter o processo modelado dentro da ferramenta. Em muitas delas, existem recursos de importação de processos de outras ferramentas, então é possível modelar o processo em uma ferramenta (ex: Visio) e importar o mesmo na ferramenta de automação.

Você citou que a iProcess tem uma relação de requisitos (centenas) para implementação de BPMS. Essa relação pode ser compartilhada aqui?

Resposta: Esta relação é um dos produtos de consultorias que a iProcess oferece no mercado. Estamos lançando, inclusive, neste mês de agosto um pacote de seleção de plataformas que permitirá que as empresas interessadas na seleção de uma plataforma de BPMS sejam preparadas para esta seleção através de um curso EAD, conheçam esta planilha e recebam diversas soluções conhecidas de mercado já avaliadas pela iProcess.

É possível termos acesso a um case ou a uma empresa para a qual a iprocess implantou uma solução desde o levantamento até a modelagem e “automação”? Gostaria de ter uma visão mais aprofundada sobre essa solução, principalmente, sobre usar um Bizagi na modelagem e usar uma ferramenta BPMS.

Resposta: Teremos o maior prazer de compartilhar cases da iProcess sobre projetos que foram da modelagem até a automação, entre em contato conosco que poderemos conversar a respeito.

De forma geral, você acha que o mercado Brasileiro tem maturidade para automação de Processos?

Resposta: Com certeza. Na verdade já existem empresas brasileiras automatizando processos há muitos anos, desde o tempo em que as ferramentas de automação de processos eram mais simples, chamadas simplesmente de Workflow. E cada vez mais empresas procuram esta iniciativa para facilitar a execução e controle dos processos. Porém, o que acontece é que algumas empresas acham que a automação de processos é a solução para todos os seus problemas, e isso nem sempre é verdade. A realização de etapas de modelagem, análise (para identificar os pontos fracos) e melhoria de processos deveriam sempre ser realizadas antes da automação, sendo que a automação só poderia ser executada diretamente se o processo já é conhecido, correto e está funcionando bem, apenas com oportunidades de melhorar sua eficiência com o uso da tecnologia.

Das 30 ferramentas, quais você considera mais eficiente, com alta usabilidade e que colabora para uma melhor visualização do desenho do processo?

Resposta: As soluções hoje de mercado tem diferenças de funcionalidade muito significativa. Não existe uma ferramenta que se destaque em relação a outras como temos, por exemplo, um Microsoft Word que é preferido pela maioria das pessoas quando o assunto é editor de texto. Por isso que é fundamental a avaliação de quais os requisitos que a empresa tem necessidade, para que somente depois a seleção da plataforma seja realizada.

As ferramentas de BPM oferecem suporte para análise das métricas ou é necessário a compra de uma ferramenta de análise a parte?

Resposta: Normalmente as ferramentas de BPM já vem com um conjunto de indicadores e dashboards padrões, que permitem o monitoramento e acompanhamento da eficiência do processo, como por exemplo tempo médio de execução do processo e atividades, as atividades e usuários que são os maiores gargalos, dentre outros. Dependendo da ferramenta, é possível criar relatórios/dashboards customizados, para indicadores específicos de negócio da organização. Além disso, algumas plataformas oferecem ainda a possibilidade de adquirir uma ferramenta epecífica de BAM (Business Activity Monitoring), voltada especificamente para o monitoramento de indicadores em tempo real.

O que você pode comentar acerca da utilidade de uso da modelagem com BPMN para apresentar a orquestração de web services?

Resposta: Se estamos falando especificamente de modelagem de processos, BPMN pode ser usada para representar quaisquer processos ou situações de negócio desejados. Existem elementos da notação que servem para representar integrações e chamadas de serviços, neste sentido a notação poderia sim ser utilizada para repreentar um processo puramente de orquestração de web services. Além disso, existe outros diagramas presente na versão 2.0 da notação, que é o Diagrama de Coreografia, que se aplica também para representar orquestração de serviços.

Como obter informações adicionais sobre o curso de modelagem para automação?

Resposta: Por favor, acesso a página da iProcess Education (www.iprocesseducation.com.br) e conheça os nossos cursos.

O levantamento de requisitos para automação é próximo ao levantamento de requisitos para implantação de sistemas?

Resposta: Com certeza. Ambos compartilham conceitos e metodologia de levantamento. O que difere é a definição dos requisitos da solução, que no caso de automação de processos é guiada sempre pelo levantamento e modelagem do processo, enquanto que no levantamento convencional é guiado através de casos de uso e necessidades específicas de aplicação.

Como é comercializado o produto citado por vocês, de relação de requisitos para adoção de um BPMS?

Resposta: Trabalhamos tanto com uma consultoria de seleção de plataformas sob medida para a sua organização como também através de um pacote contendo um curso de seleção, a planilha preenchida e uma série de ferramentas já avaliadas.

Processos com integração com outros sistemas os campos de integração e e os mock ups devem ser feitos antes de implementar no sistema as entidades ?

Resposta: É fundamental que no momento que se identifique a necessidade e viabilidade de uma determinada integração do processo com um sistema, que a assinatura desta integração seja acordada entre a equipe de processos e a equipe do sistema. Neste caso, caberá a equipe do sistema garantir que a assinatura acordada pode ser disponibilizada, mesmo que ainda existam pendências técnicas do lado do sistema para a sua disponibilização.

 

Como documentar funcionalmente o processo de negócio como requisito de software

Na automação de processos, os processos de negócio são definidos e otimizados a fim de serem executados sobre uma arquitetura de sistemas informatizada.

No artigo Benefícios da Automação de Processos do blog da iProcess, tratamos dos benefícios e vantagens da automação de processos, estabelecendo uma visão dos ganhos obtidos quando se automatiza um processo. Porém, alguns cuidados devem ser tomados para escolher um processo a ser automatizado e estabelecer o nível de detalhamento necessário do processo para tal, tendo como objetivo automatizar processos com tarefas que possam efetivamente demonstrar bons resultados. Em Estudo de Caso: Automatizar o processo (ou não)? Eis a questão! exploramos esta questão através de um estudo de caso.

As etapas de modelagem na transformação de um processo

Nos projetos de implementação de BPM, o ciclo BPM a ser seguido inclui a análise (AS IS) e o redesenho (TO BE) dos processos, antes de seguir para a etapa de implementação (TO DO). Desta forma, garante-se que o cenário atual do processo na organização foi adequadamente estudado e todas as necessidades de melhoria no processo foram devidamente contempladas.

O artigo BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado aborda este tema, incluindo aí os riscos envolvidos em um projeto em que se parte diretamente para a etapa de implementação (TO DO), sem passar pelas demais. Isto porque é na etapa de TO BE, em que há a proposição de melhorias no processo e são definidos os requisitos de software que irão compor a solução automatizada. Já falamos sobre esta ligação no artigo O que BPM tem a ver com requisitos de software? Tudo!, enfatizando que os requisitos de software são identificados a partir do processo.

Documentando a modelagem do processo para automação (TO DO)

Passadas todas estas fases, chega a hora da implementação do processo. O processo e os requisitos de software complementares serão detalhados funcionalmente (TO DO) e implementados pela equipe de desenvolvimento. E aí entra em cena a Especificação Funcional do processo. Ela especifica o fluxo a ser automatizado no BPMS e sua estrutura de dados, regras para identificação de participantes e comportamento de cada componente.Resumidamente, a Especificação Funcional deve atender aos seguintes objetivos:

  • Concentrar as informações do processo de negócio necessárias para a automação do processo;
  • Utilizar linguagem que deve ser de fácil compreensão pelo público-alvo;
  • Fornecer informações suficientes para que o projetista possa desenvolver a especificação técnica do processo;
  • Servir de referência para o desenvolvimento e homologação da solução.

Temos encontrado, ao longo dos projetos de automação de processos em que a iProcess atua, alguns clientes que já possuem uma metodologia, utilizam ferramentas e templates para documentar processos automatizados, enquanto outros não possuem nada definido. Nas organizações que já tenham adotado uma metodologia de desenvolvimento com documentação funcional dos requisitos, é comum encontrarmos documentos como Casos de Uso, Especificações de Interface, Especificações de Serviço ou de Regras de Negócio. Nos projetos de automação de processos, é comum que os requisitos se estendam além da programação do fluxo no BPMS, envolvendo o desenvolvimento ou customização de componentes adicionais ao processo, como aplicações de apoio, cadastros de backoffice e serviços de integração com outros sistemas. Para estes requisitos, os documentos já adotados pela TI continuam sendo bastante apropriados. 

 Assim, a Especificação Funcional do Processo (o modelo TO DO) vem para complementar a documentação do sistema definindo funcionalmente o processo de negócio, e requer um detalhamento de como o fluxo do processo se comportará ao ser automatizado. São informações importantes neste modelo:

  • Diagrama do processo automatizado;
  • Modelo de dados do processo;
  • Identificação de usuários ou grupos de usuários participantes do processo (Papéis);
  • Formulários do Processo;
  • Especificação dos componentes do processo, que são eventos, tarefas humanas e automáticas, notificações/envios de email, controles de tempo, gateways, subprocessos, regras de negócio e sensores de indicadores;
  • Definições de interface para as atividades humanas;
  • Referências a serviços de outros sistemas;

Esta especificação deve ser realizada por um Analista de Processos e Sistemas, ou um analista de sistemas que tenha desenvolvido uma visão de processos, horizontal aos sistemas, e que conheça as capacidades de implementação do BPMS adotado pela empresa

O Analista de Processos e de Sistemas, pode encontrar alguma dificuldade em estabelecer a melhor forma de como escrever utilizando uma linguagem de fácil compreensão pelo usuário e ainda assim fornecer informações suficientes para que sirva de referência para a elaboração da especificação técnica e o posterior desenvolvimento da solução. Uma sugestão nesta situação é o alinhamento com os responsáveis pela aprovação do documento no cliente, para estabelecer qual será o nível de detalhamento da Especificação Funcional do processo, a fim de definir se haverá necessidade de utilizar documentos complementares mais técnicos para a equipe de desenvolvimento, ou em mais alto nível para a equipe de negócio.

Temos observado que, às vezes, o cliente opta por realizar uma “tradução” da especificação para a área de negócio ou absorver para si a aprovação do documento. Quanto mais precisa for a Especificação Funcional do processo, menos problemas de entendimento tendem a ocorrer entre a expectativa do cliente e o que está sendo desenvolvido. Isto porque as etapas de desenvolvimento e homologação dos processos vão utilizar estas informações, garantindo assim, que o que foi definido e aprovado pelo cliente seja entregue.

Cabe aqui salientar que a Especificação Funcional do processo, assim como de sistemas, não fica “congelada”, sem receber as atualizações que ocorrerem no escopo do projeto durante o seu ciclo de vida. Ajustes na documentação funcional podem ser necessários após a finalização da etapa de especificação funcional por diversos motivos e devem ser realizados, sempre que necessário, para que se mantenha a consistência entre o que foi especificado e o que foi desenvolvido. E neste caso, a gestão de mudanças do projeto é que tratará desta atualização.

Se este assunto lhe interessou, no nosso curso iPE03 – Modelagem de Processos para Automação, reservamos um capitulo inteiro para tratar deste assunto, inclusive com exercícios práticos.

Webinares iProcess 2015 – BPMN: Modelando a comunicação entre processos

O webinar de “BPMN: Modelando a comunicação entre processos” foi apresentado ao vivo pela internet em 10/09/2015 pela Kelly Sganderla com uma centena de participantes! Nesta postagem, publicamos o vídeo gravado, a apresentação e as perguntas enviadas durante o evento.

A comunicação entre participantes internos, externos e entre processos na modelagem BPMN, apesar de simples, pode gerar muitas dúvidas nas modelagens iniciais. Como represento que um participante passa o processo para o próximo? Como modelo a situação em que um fluxo quando termina deve dar início a outro? Neste webinar, apresentamos como cada situação deve ser modelada de acordo com o uso padrão da notação, as diferentes abordagens possíveis e vantagens em cada uma.

Os slides da apresentação também estão disponíveis no slideshare:
http://pt.slideshare.net/iProcessBPMeSOA/bpmn-modelando-a-comunicao-entre-processos-webinares-iprocess-2015

Confira abaixo as respostas para as perguntas enviada durante o evento:

I. Perguntas sobre a transferência do processo entre participantes do mesmo fluxo:

Pergunta: “Se vc não representa o “encaminhar/receber” e houver um leadtime enorme entre essas tarefas? Ao suprimir essa passada de bastão vc não corre o risco de não observar oportunidades de melhorias?”
Resposta: Em BPMN, a passagem do processo de um participante para outro está implícita no fluxo de sequência (sequence flow). “Encaminhar” faz parte da condição de término da tarefa que foi concluída, assim como o recebimento é uma premissa para a tarefa seguinte. Entretanto, há casos em que o transporte do processo em si é uma tarefa a ser medida. Por exemplo: se houver uma situação em que o processo é entregue a uma assistente de protocolo, que dará registro de entrada e então passará para um analista realizar a avaliação – bom, estas duas são de fato tarefas diferentes. Mas então, o trabalho é “Receber” ou é “Protocolar o recebimento”? Cada caso precisa ser avaliado frente ao modelo que estamos criando, mas por definição a passagem do processo para a próxima atividade (independente de quem a realize seja a mesma pessoa ou uma pessoa diferente) está implícita na transição de fluxo de sequência (sequence flow) (veja mais no vídeo em 36’00).

Pergunta: “No caso das atividades ‘Enviar’ e ‘Receber’ existe o COMO é enviado e o COMO é recebido. Neste caso, não é necessário informar o COMO? Ex.: e-mail, via workflow, formulário, etc… A pergunta serve também para no caso de gatilhos se é necessário registrar o COMO?”
Resposta: O propósito da notação BPMN é possibilitar a criação de diagramas que representem a lógica do processo. Informações complementares como ferramentas, meios de compartilhamento da informação, etc fazem parte da modelagem física, que contempla uma documentação complementar, e que em geral não fica explícita no diagrama. É claro, pode-se utilizar elementos como data object (objeto de dados) para representar o fluxo de documentos, formulários de apoio entre outros, mas essa representação não é obrigatória em BPMN, e deve ser usada com cuidado. Afinal, o que é o mais importante no seu diagrama: colocar toda a informação em uma visão única porém de difícil leitura, ou facilitar o entendimento de o quê é realizado pelo processo até o seu resultado final? (Veja mais no vídeo, em 42’35”).

II. Perguntas sobre as abordagens de Orquestração x Comunicação:

Pergunta: “Podemos unir, em um fluxograma, a comunicação com a orquestração?”
Resposta: Sim, você pode ter a combinação de elementos usados nas duas abordagens, mas nossa recomendação é que, na estruturação de modelos de processo complexos, defina-se uma abordagem preferencial da organização, visando uma padronização nos diagramas (veja mais no vídeo, em 41’27”).

Pergunta: “Qual abordagem é mais utilizada? Comunicação ou Orquestração?”
Resposta: Não temos uma medição de qual a abordagem mais usada pelas organizações. Temos visto modelos usando os dois casos. Para esta opção recomendamos considerar: eventuais limitações da ferramenta, a maturidade e a cultura de processos da organização e que essa seja uma definição organizacional, propiciando uma modelagem padronizada em toda a arquitetura de processos da empresa.

Pergunta: “Alguma destas duas abordagens é mais ou menos recomendável ao usar uma ferramenta BPMS para a automação de processos ao usar BPMN?”
Resposta: Esta questão está intimamente relacionada à aderência do BPMS à notação. Algumas soluções, por exemplo, não permitem representar pools black box externas ao processo modelado, o que inviabiliza a adoção da abordagem por comunicação. Outras não contemplam elementos de subprocesso reusável, dificultando a escolha pela abordagem de orquestração.

Pergunta: “No diagrama geral de orquestração não há partes envolvidas (lanes) e não há atividades. Esta forma de modelagem é intencional? Se sim, qual é o nível de granularidade mais adequado para separar processos em subprocessos?”
Resposta: BPMN considera o uso de pools e lanes como representação meramente visual na modelagem dos processos. Você pode ter processos modelados sem representar pools e lanes e ainda assim ter um modelo de processo válido.
A estruturação de um processo em subprocessos varia de caso para caso, e pode ter múltiplos níveis também. Não há uma regra para isso.

Pergunta: “Eu utilizo a visão de orquestração para dar uma visão macro do processo e depois desenho todo o processo com o miles para representar os subprocessos e facilitar a visão do todo, está correto?”
Resposta: “Miles” (acredito que seja uma referência a milestones) não é um elemento da notação BPMN. Ela é uma extensão visual agregada por algumas ferramentas (como o Bizagi, por exemplo). Se no seu segundo desenho todo o fluxo é parte de um único diagrama de processo, então o que você tem é uma representação mais detalhada do mesmo processo, que é o caso do exemplo inicial – em que todo o fluxo é um único processo.

III. Apesar do foco do webinar ser sobre o encadeamento de processos para formar o processo de negócio de ponta-a-ponta, diversas dúvidas sobre outros elementos de BPMN foram enviadas pelos participantes, com base no exemplo usado no webinar, e que não podemos deixar de responder:

Pergunta: “Recebemos a informação que é necessário sempre colocar na sequência da direita, mas a seta pode retornar as atividades anteriores, e não repetir a mesma atividade seguindo a sequência.”
Resposta: Não há restrições sobre a direção da seta de entrada nem de saída em nenhum elemento de fluxo em BPMN. As boas práticas recomendam desenhar o processo da esquerda para a direita já que é a forma como naturalmente lemos as informações, mas um processo pode ter fluxos desenhados em qualquer direção. (Veja mais no vídeo em 44’14”).

Perguntas:
– “Na apresentação da modelagem as atividades não estavam identificadas como ‘Manual’ de ‘Usuários’, etc… algum motivo especial ou não é relevante para este tipo de processo?”

– “As tarefas não deveriam pertencer e ser representadas com um tipo de tarefa ou independe disso no exemplo?”
– “Qual a diferença de tarefa manual e de usuário?”
Resposta: A definição dos tipos de tarefas não é uma obrigatoriedade na modelagem de BPMN. Em um processo manual (que será disponibilizado como um guia e interpretado pelas pessoas) essa classificação realmente não faz muita diferença. Já na modelagem de um processo automatizado em um BPMS, cujas atividades serão interpretadas pelo sistema, definir o tipo de tarefa é fundamental (veja no vídeo em 38’25”).
Se você ainda tem dúvidas sobre os tipos de tarefas, confira essa série de três artigos que explicam bem as diferenças entre eles:
Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual
Desmistificando tipos de tarefas em BPMN: Tarefas automáticas
Desmistificando tipos de tarefas em BPMN: Tarefas de envio e recebimento.

Perguntas:
– “Não teria q ter um gateway no primeiro loop do processo?”

– “Antes da primeira tarefa do Assistente de viagem não deveria conter um gateway, em função de várias outras tarefas estarem conectadas a ela?”
Resposta: É possível sim que qualquer elemento de fluxo tenha mais de uma entrada. O gateway antes poderá deixar mais explícita a lógica da chegada dos fluxos na atividade, mas se não há gateway controlando esses fluxos de sequência, o comportamento é como de um gateway exclusivo (veja mais no vídeo em 33’48”).

Pergunta: “Posso ter gateways seguidos (um após o outro)? Após a tarefa ‘Providenciar inscrição em evento’?”
Resposta: A especificação de BPMN não impõe nenhuma limitação sobre isso. Especialmente se a lógica dos gateways for diferente, então pode fazer sentido ter gateways em sequência. Sabemos que a melhor documentação é aquela que consegue ser mais objetiva, e assim se temos uma situação com vários gateways encadeados, é importante se questionar: se eu pensar além das respostas “Sim/Não”, posso resolver o problema de roteamento do meu processo com apenas um gateway? Se sim, então esta com certeza será a melhor opção, já que simplifica o diagrama.
Veja mais sobre uso de gateways neste artigo:
Estudo de caso: Boas práticas no uso de gateways em BPMN

Pergunta: “Você poderia explicar melhor esse P1 e P2 na atividade ‘Realizar prestação de contas’?”
Resposta: Esta pergunta refere-se aos dois eventos de borda de tempo (timer intermediate border event) não interruptivos conectados à tarefa de Realizar Prestação de Contas (veja no vídeo, em 10’38). Estes eventos de borda controlam prazos que se ocorrerem, dão início a outras atividades, no caso, de acompanhamento do processo.

Pergunta: “Quando estamos desenhando AS-IS, como representamos a forma como a comunicação é feita (e-mail, serviços em um barramento (SOA), em mãos) se usarmos a abordagem de orquestração? A forma como os subprocessos são acionados é importante para o entendimento do mesmo. Concorda?”
Resposta: Esta pergunta tocou em um ponto chave! O que determina como os subprocessos são acionados é o processo orquestrador. Ele é o responsável por determinar quando um subprocesso deve ser iniciado e garantir que as informações “desçam” e “subam” a cada execução desses subprocessos, de forma que o processo orquestrador tem sempre toda a informação que foi sendo acumulada durante seus subprocessos. Quais informações, e o meio como isso ocorre, não é detalhado no fluxo, mas na especificação detalhada de cada uma das tarefas.

Pergunta: “Qual é o meio de comunicação utilizado pelos participantes do processo?”
Resposta: Isto é independente da lógica do processo. Se os participantes se comunicarem através da troca de e-mails, ou se for um formulário de papel que passa de mão em mão, a lógica, ou seja, a sequência de atividades, as dependências e as responsabilidades sobre elas permanecerá a mesma.

Pergunta: “Os objetos de sistema e doc não podem ser utilizados para representar a comunicação via email ou sistema assim como era utilizado no EPC?”
Resposta: A notação BPMN não contempla estes elementos citados (sistema, doc), mas eles podem ser criados como extensão pela ferramenta de modelagem. Utilizá-los, neste caso, deve ser uma definição da própria organização.

IV. Outras questões enviadas, indiretamente relacionadas ao tema:

Pergunta: “Quais os BPMS mais consagrados de mercado?”
Resposta: Esta é uma questão na qual não encontraremos consenso no mercado. O que definirá um BPMS como “consagrado”? O número de cases? A variedade de cases? O volume de processos? A complexidade dos processos? A presença no Brasil? Ou no mundo?
Se for a presença no Brasil, uma boa fonte de informação pode ser a Pesquisa Nacional em Gerenciamento de processos de Negócio da ABPMP Brasil, publicada na 10ª edição da revista BPM Global Trends.
Outra fonte pode ser o relatório do Gartner Group e seu Quadrante Mágico de iBPMS (mas esse relatório não avalia nem 10% das soluções que existem ao redor do globo, apenas grandes players).
Para entender a complexidade na definição de critérios para comparação e avaliação de BPMS/iBPMS, assista ao Webinares iProcess 2014 – Etapas e Desafios da Seleção de uma Plataforma de BPM.

Quer participar dos próximos?

Webinares iProcess 2015 – Desafios comuns em um projeto de BPM

Nesta postagem, compartilhamos a gravação do webinar de “Desafios comuns em um projeto de BPM”, apresentado pelo Eduardo Britto em 11/08/2015.

Os projetos de redesenho e automação apresentam desafios que, quando conhecidos, podem ser evitados ou mitigados.
Neste Webinar, apresentamos alguns dos desafios mais comuns em projetos de BPM para que possam ser tratados antes que se tornem problemas.

Os slides da apresentação também estão disponíveis no slideshare:
http://pt.slideshare.net/iProcessBPMeSOA/desafios-de-um-projeto-de-bpm-webinares-iprocess-2015.

Confira abaixo as respostas para as perguntas enviadas durante o evento:

Pergunta: “Existe alguma forma mais clara de modelar quando há integrações entre sistemas? Entradas e Saidas?”
Resposta: Esta pergunta é bastante específica em relação à modelagem de processos. Uma das formas mais claras de se representar essa modelagem em BPMN é utilizando uma tarefa de serviço no processo comunicando-se com o sistema que realiza a respectiva operação através de message flows uma para representar a entrada e outra para representar a saída. Se o processo, entretanto, é na verdade uma sequência de interações entre sistemas, talvez seja interessante avaliar o uso do Diagrama de Coreografia de BPMN para representá-lo. No artigo BPMN 2.0 – Novos Diagramas e Elementos: Introdução a Coreografia apresentamos este diagrama e seus elementos.

Pergunta: “Qual um tempo médio para acompanhar a execução do processo para avaliar seus seus resultados?”
Resposta: Este tempo pode variar de acordo com a própria duração do processo. Enquanto há processos de longa duração (que do início ao fim levam anos para terem suas tarefas concluídas) outros processos são executados completamente em um mesmo dia. Outro aspecto que pode levar a uma variação é o volume de processos executados em um determinado período. Alguns processos geram grande volume de informações diárias de desempenho, outros precisam de dias e dias para gerar novas informações atualizadas. Tudo isso precisa ser levado em conta para se determinar o tempo e frequência de acompanhamento do monitoramento, e isso pode variar de processo a processo.

Quer participar dos próximos?

Webinares iProcess 2015 – Plataformas BPM: Como um mesmo requisito pode ser atendido de formas diferentes

Nesta postagem, compartilhamos a gravação do webinar de “Plataformas BPM: Como um mesmo requisito pode ser atendido de formas diferentes”, apresentado pelo Carlos Mortari em 16/07/2015.

Este foi o terceiro seminário da série de webinares da iProcess em 2015, realizado ao vivo! Mais uma vez, nosso agradecimento especial aos participantes que acompanharam a transmissão on line e contribuíram enviando suas dúvidas e questões sobre o tema.

Os slides da apresentação também estão disponíveis no slideshare:
http://pt.slideshare.net/iProcessBPMeSOA/plataformas-de-bpm-comparando-requisitos-webinares-iprocess-2015

Confira abaixo resposta para pergunta enviada durante o evento:

Pergunta: “Em uma organização que ainda está iniciando sua empreitada, com BPM (de 1º ou 2º nível de maturidade) em qual momento devemos partir para o investimento em uma plataforma de BPMS, que tem um alto custo para a organização e que necessita também de investimentos adicionais em treinamentos. A partir desta decisão quais requisitos de plataformas, poderia nos levar a usar um “open source” (bonita por exemplo) vs uma licença paga (oracle, tibico, IBM, etc)? “
Resposta: Idealmente, a escolha da plataforma que irá suportar as iniciativas de BPM deveria ser feita no início, num cenário em que esteja claro para a organização quais são as suas necessidades atuais e futuras. A escolha de uma ferramenta “quebra-galho” para tocar iniciativas de processos pode até atender num primeiro momento, mas existe o risco de apresentar dificuldades e limitações posteriormente, quando a empresa já está mais estruturada e pode necessitar de uma solução mais robusta para apoiar o gerenciamento de processos. Nestes casos, existe a chance de ocorrer retrabalho e necessidade de migração dos processos de uma solução para outra.
Quanto a ferramentas open source, elas podem ser uma boa alternativa quando se deseja testar os recursos de uma solução de BPMS e realizar provas de conceito, por exemplo. Porém, é preciso ficar atento porque em alguns destes produtos as versões “free” não oferecem recursos bem importantes, podendo limitar o uso da solução em produção. Além disso, embora possam existir fóruns de discussão e membros da comunidade atuantes, a falta de um suporte oficial e SLAs definidos podem gerar dificuldades, caso sejam encontrados problemas em ambiente de produção que necessitam de solução mais urgente.

Quer participar dos próximos?