Publicações arquivadas sob BPMN
Você já ouviu - ou já falou - alguma das seguintes frases:
“- Tenho meus processos mapeados no Visio. O seu BPMS importa de lá para executá-los?”
“- Será muito simples. É só clicar em um botão no Aris e BUM!!, meus processos serão executados no BPMS”
“- Vai ser fácil o projeto. Ano passado uma consultoria mapeou os nossos processos, está 50% pronto.”
“- Não quero retrabalho. Não quero ter que desenhar de novo os meus processos só para automatizar”.
“- Quero uma ferramenta onde o usuário desenhe em BPMN e depois a TI só execute o BPEL gerado sem trabalho”
Eu ouço isso praticamente todo o dia. Essas questões, de um jeito ou de outro, refletem uma ansiedade comum em relação a existência do que chamo de “mito do elo perdido de processos”. Como venho da área de TI, que gosta de colocar siglas em tudo, vou chamar amistosamente de “MEPP“.
Assim como os evolucionistas procuram em vão a séculos o elo perdido entre os macacos e os homens, o MEPP representa a busca sem fundamento do elo direto entre o mapa do processo de negócio e a sua execução, ou o processo automatizado. Explico.
Mapear (desenhar) um processo é um meio, e não um fim. Isso está mais que provado e discutido. Antes de iniciar o desenho de um processo, ou mesmo uma iniciativa de processos, tenho que me perguntar: “OK, processos. Mas para quê quero processos? Qual é o objetivo do meu desenho, do meu mapeamento, da minha modelagem?”. Algumas respostas poderiam ser, entre outras:
- Para entender melhor como minha empresa funciona e descobrir gargalos;
- Para entender melhor porque esse processo leva tanto tempo e melhorá-lo;
- Para otimizar o fluxo de informações e pessoas envolvidas no processo;
- Para gerar uma documentação completa de modo que um funcionário novo seja facilmente treinado;
- Para obter a certificação X, Y ou Z;
- Para selecionar e customizar um ERP;
- Para automatizar em um BPMS;
- etc…
O fato é que, dependendo do objetivo selecionado, o analista de processos deve adaptar sua ferramenta - o mapa do processo - para um maior ou menor nível de detalhe. Dependendo do objetivo, determinadas interações deverão ser contempladas ou não. Você já se deparou com a questão “será que junto essas duas atividades em uma só no meu mapa” ou mesmo “o que representa uma atividade?”. A resposta para tudo sempre será: depende do seu objetivo.
Isso significa que o seu processo de compras, por exemplo, pode ser desenhado de 10 maneiras diferentes, e todas podem estar certas. Vai depender do objetivo. Arrisco dizer que, mesmo seguindo o mesmo objetivo, duas pessoas podem desenhá-lo diferente, e ainda assim as versões estarem corretas. Um dia vou fazer esse teste.
Vamos a um exemplo prático. Veja o fluxo abaixo:
Simples, não? Tão simples que nem precisa de explicação. Agora imagine utilizarmos o botão mágico para extraordinariamente automatizá-lo no BPMS, usando o conceito de MEPP. Sabe o que irá ocorrer? Isso:
1. Seu João, responsável pelo setor de entregas, recebe uma tarefa no BPMS dizendo pra ele pegar uma televisão 21 polegadas de código XY1234 no estoque;
2. Seu João pega a TV, volta ao computador e avisa ao BPMS que terminou a atividade;
3. Imediatamente o BPMS avisa seu João que agora ele deve imprimir e anexar a nota fiscal de transporte na caixa da TV;
4. Seu João, um cara obediente, faz exatamente o que o BPMS manda e depois de anexar a NF, orgulhosamente avisa o BPMS que concluiu no prazo a atividade;
5. O BPMS lembra Seu João que ele tem que levar a TV para dentro do caminhão;
6. Seu João coloca a TV dentro do caminhão e volta feliz ao computador, avisando ao BPMS que concluiu com sucesso a operação!
E isso ocorre para todos os produtos que a empresa vende em um dia.
Rídiculo, não? Apesar de o mapa do processo estar correto e coerente com o negócio, e talvez coerente com um objetivo de “entendimento ou treinamento no processo”, obviamente esse mapa não serve de nada para a automação. Parece simples vendo isso agora, mas muitas vezes no meio de um grande processo isso passa despercebido.
O problema é que, ao final, existem dezenas de incoerências como essa em um processo desenhado, e a ligação entre os dois modelos é exatamente o elo perdido, ou MEPP, dos processos - algo que nunca existiu.
Fornecedores vendem softwares com botões mágicos que transformam o “modelo de negócio” para o “modelo de automação”. Clientes não querem retrabalho de tirar o seu processo da ferramenta de mapeamento para a ferramenta de execução; querem que isso seja automático. Conhece a fábula da fome e da vontade de comer? Você acredita que exista software tão inteligente a ponto de automaticamente compreender a semântica do processo - ou seja, o que ele significa - e magicamente convertê-lo para um modelo executável? Não existe.
Por isso a pergunta “o BPMS importa meus processos do Visio ou do Aris?” na grande maioria das vezes é irrelevante frente a diferença semântica entre o processo originalmente desenhado e o processo a ser executado. A não ser, é claro, que o processo tenha sido, desde o princípio, desenhado para o fim de automação.
Então terei retrabalho de desenhar de novo, só que dessa vez diferente, os meus processos? Sim, terás. A questão é como você irá abordar isso. Em minhas experiências observei que esse é um trabalho 50% braçal, 30% seguir regras e 20% pensar. Cabe a você decidir se irá fazer isso por si mesmo ou irá passar para outra pessoa fazer - alguém que tenha mais tempo livre e custo (valor-hora) inferior ao seu.
11 de Agosto de 2008 às 00:57
Rafael Bortolini
Update 31.07.2008: quer saber o que estudar para a prova? Veja aqui: http://blog.cryo.com.br/2008/07/31/o-que-estudar-para-o-exame-de-certificacao-oceb/
Finalmente o mundo passa a conhecer uma certificação real, válida e realmente consistente para profissionais de BPM. Eu estava com medo de que, em um mercado em ascensão, alguma organização, entidade ou empresa sem representatividade real lançasse um programa de certificação e esse fosse tomado pelo mercado como verdade. Por que, como eu sempre digo, quem chega primeiro sai em vantagem.
Hoje eu fiz a primeira prova de certificação do OCEB – OMG Certified Expert in BPM. É um conjunto de 5 provas, sendo que somente a primeira, chamada OCEB Fundamental, foi lançada, e ainda em formato BETA. Isso significa que não será a prova final ainda, eles estão testando modelos de provas diferentes com beta-testers para chegar em um formato adequado.
O interessante dessa certificação é que ela é orquestrada pela OMG, uma instituição internacional que, entre outras coisas, controla o UML, o BPMN e o BPMM. Nada mal, hein? Acredito que não poderia haver um sponsor melhor.
Quer ser um beta-tester e fazer as provas de graça, antes de tudo mundo? Clique aqui e siga as instruções. Com certeza, até o final desse ano, essa certificação vai ser obrigatória para quem trabalha na área. Abaixo você vê um esquema das provas de certificação.
Pois bem, vamos ao que interessa: a prova de hoje. Trata-se de um teste com 249 questões objetivas, sobre fundamentos de processos e BPM. A prova final, depois do beta teste, provavelmente terá menos questões. O tempo para fazer essas 249 questões é de 4 horas, senão me engano. Antes do teste, você assina um termo de compromisso concordando em não detalhar ou explicitar as questões da prova para as demais pessoas. Mas posso adiantar que o escopo da prova engloba questões sobre:
- Estratégia e marketing em geral
- Conceitos de BPM e seus elementos dados por autores renomados da área (veja aqui)
- Diversos tópicos sobre BPMM
- Diversos tópicos sobre BPMN, inclusive com questões de interpretação de fluxogramas
- Uma parte final sobre um apanhado de conceitos de processos, onde entra Lean, Six Sigma, Qualidade Total, Reengenharia, etc…
Não achei uma prova difícil. É um pouco cansativa, talvez. O resultado? Eles não divulgam para quem faz beta teste, somente após o final dessa fase eles irão compilar os resultados e informar sua pontuação.
3 de Julho de 2008 às 00:37
Rafael Bortolini
Atualização 05.05.2008 – Vagas esgotadas! Obrigado pelo interesse!
Estamos com as 2 (DUAS!) útimas vagas para o cursinho gratuito de BPMN via webconferência, que eu estarei ministrando na próxima terça-feira, dia 06 de maio. Será 1 hora de introdução e revisão das principais informações sobre a especificação. Corra para se inscrever, antes que acabe.
4 de Maio de 2008 às 19:23
Rafael Bortolini
Dias atrás, falamos sobre o BizAgi, uma ferramenta gratuita de modelagem de processos usando BPMN. Trata-se de um software muito interessante por ser simples e completo ao mesmo tempo. Com certeza, é uma ótima opção.
Voltando agora do primeiro BPM Forum Day, foi muito legal conversar com diversos consultores e representantes de empresas que já estão utilizando o software. Ele se espalhou rapidamente, em poucas semanas. O pessoal é unânime em dizer que seu foco exclusivo em desenhos BPMN facilita bastante o uso. É o contrário de softwares como o Microsoft Visio, por exemplo, que possui um milhão de notações diferentes: você nunca sabe qual usar e no final da sua vida usou só duas ou três notações diferentes.
O mais interessante do BizAgi, entretanto, é um ponto que a maioria das pessoas não chegou ainda: a possibilidade de exportar o modelo para XPDL e importar numa ferramenta BPMS, “gerando” uma aplicação quase que instantaneamente. Isso sim é muito legal!
às 19:01
Rafael Bortolini
Eu sempre achei o o BPMN uma especificação exageradamente grande, com 52 elementos disponíveis para uso.
A primeira vez que senti isso na prática foi logo em um dos primeiros cursos que ministrei sobre o assunto. Esse curso foi dividido em 2 etapas. Na primeira etapa nós iríamos revisar todos os elementos do BPMN. O pessoal, então, deveria voltar para casa e desenhar alguns fluxogramas. Na segunda etapa, iríamos revisar os fluxogramas desenhados.
Foi engraçado notar que muitos alunos do curso tentaram, de todas as maneiras, utilizar o maior número de elementos diferentes nos seus desenhos. O pessoal esqueceu o velho ditado que diz que “menos é mais”, e tornou seus processos um grande carnaval de objetos. Praticamente ininteligíveis. Parecia que quem conseguisse “encaixar” mais elementos diferentes ganharia algum tipo de prêmio ou concurso. Obviamente, muitos elementos estavam sendo usados erroneamente.
A partir desse momento, em um curso ou projeto de consultoria, a primeira coisa que faço é sempre focar em um roll pequeno de elementos, os mais básicos possíveis, e obrigar todo mundo a usar esses, e somente esses objetos. O desenho do processo fica mais simples, mais fácil de compreender e muito mais claro.
Os objetos abaixo, além de pools, lanes e das setas de conexão, são os que considero básicos para uso. Afora esses, peço para a pessoa pensar duas vezes antes de desenhar:
Não foi surpresa, portanto, ler o artigo “How much BPMN do you need”, de Michael zur Muehlen e Jan Recker. Esse pessoal analisou 126 diagramas BPMN desenhados por empresas e consultores diversos e procurou padrões entre eles. Olhe que interessante:
- Nenhum dos diagramas usou mais de 15 elementos diferentes, e nenhum usuou menos que 3;
- A média foi 9 tipos diferentes por fluxo, ou seja, menos de 20% do subset total do BPMN;
- 5 elementos do BPMN nunca foram usados em nenhum diagrama;
Tem diversas outras conclusões interessantes no artigo. Dê uma espiada lá.
24 de Abril de 2008 às 22:52
Rafael Bortolini
Dica do Derek Miers, do BPM Focus.
A BizAgi lançou recentemente uma versão free da sua ferramenta de desenho de processos em BPMN. De acordo com o Derek, é a melhor ferramenta BPMN que ele já viu.
Achei ela muito boa. É muito fácil e simples de usar, e focada 100% no BPMN 1.1. Não tem como errar. Um dos recursos mais interessantes, entretanto, é a possibilidade de você fazer o desenho, exportar para o formato XDPL e, eventualmente, importar em um BPMS completo (coisa que no Visio, por exemplo, você teria que pagar a mais para conseguir).
Para quem vai usar, é especialmente interessante o recurso “Smart Align”, que ajuda a posicionar corretamente os elementos e deixar o fluxo certinho. Senti falta, entretanto, de uma maior possibilidade de interação do desenho com o teclado. Segue abaixo um print da tela. Para fazer o download da ferramenta, é por aqui.
23 de Abril de 2008 às 14:35
Rafael Bortolini
Você, que está usando o Windows Workflow Foundation – WWF para desenvolver algumas aplicações orientadas a processos, usando o “Sequential Workflow”, já notou que ao tentar desenhar um fluxo como o abaixo, desenhado usando BPMN, não consegue?
O processo tem uma regra de negócio básica, presente em qualquer processo de empresa: da atividade A, uma condição é avaliada e o processo segue para B ou C. Se for para C, após essa atividade, deve voltar para “A”. O modelo “Sequential Workflow”não permite diretamente esses “loops” para pontos passados do processo, da mesma maneira que processos baseados em BPEL também não deixam. Isso pois o modelo XAML, utilizado pela Microsoft para descrever os processos do WWF, similarmente ao BPEL, é em formato bloco-estruturado, onde cada “perna” do processo deve ser fechada antes de o processo continuar, e onde não é possível referenciar elementos anteriores.
A solução? Vemos algumas:
- Existem alguns métodos na internet que chamarei carinhosamente de “gambiarra” para representar uma volta no “Sequential Workflow”, e que prefiro não citar aqui;
- Posso redesenhar o fluxo acima, tornando-o compliance com o XAML. Isso foi demonstrado no nosso post anterior, onde falamos sobre a diferença entre e o BPMN e BPEL;
- Posso utilizar o outro modelo de workflow do WWF, o “State-Machine”. Apesar de bem mais flexível, esse modelo é muito distante do modo como os processos são mapeados usando BPMN pelos analistas de negócio, fazendo com que o projeto técnico final fique destoante de uma fase de levantamento e mapeamento dentro de um projeto de BPM;
Você conhece outra alternativa? Colabore e faça um post aí.
Por esses e outros motivos, nos projetos em que trabalho, o WWF tem tido maior utilidade em processos de menor complexidade, como workflow básico (aprovações, revisões, etc…) e pequenas integrações. Em processos de colaboração complexa com mais de 50 atividades e uma infinidade de possibilidades, o WWF pode dificultar.
6 de Outubro de 2007 às 16:15
Rafael Bortolini
Um dos assuntos mais importantes em BPM, com certeza, é a integração entre o modelo de negócio do processo, desenhado por um analista, e o modelo de execução, gerenciado por um técnico. Para grande parte das plataformas e projetos hoje, é integração entre o desenho BPMN e a execução BPEL do processo. O fato é que, apesar do que vemos com grande destaque no mercado, essa integração não é nada, nada, nada simples e direta, dando origem ao conhecido problema de round-tripping.
O round-tripping consiste na possibilidade de manter sincronizado o desenho de negócio, feito em BPMN, e a aplicação de execução do processo, em BPEL. Consiste em poder alterar o modelo de negócio do processo e que essa mudança seja facilmente replicada para o sistema. E vice-versa também, ou seja, que a alteração de um processo que está sendo executado em um sistema seja automaticamente propagada para o modelo de negócio, ou BPMN (deixando assim a “documentação” sincronizada com o “sistema”). Qualquer semelhança com o problema de atualização dos modelos UML de uma aplicação em manutenção não é mera coincidência.
A boa notícia é que diversas ferramentas de mercado destacam que conseguem fazer esse processo de sincronização “nativamente”. A má notícia é que em muitos casos isso não é tão “nativo” e direto assim. Na prática, quero mostrar que esse round-tripping é um assunto extremamente complexo e que deve ser levado muito a sério.
Vamos a um exemplo prático. Meu analista de negócio mapeou o seguinte processo seguindo a notação BPMN:
É um processo simples. Após o início uma condição é avaliada e o processo segue para um lado ou para o outro. Se o valor do investimento for menos do que 10.000 será enviado para um assessor, se for maior do que 10.000, para aprovador verificar. Se for para o assessor e for de alto risco, ainda assim o aprovador será acionado.
O fato é que, ao passar esse simples fluxograma para o modelo BPEL, “emperramos” e não conseguimos representá-lo nessa linguagem. Esse fluxograma simplesmente não é compatível com o modelo BPEL.
A representação de um processo em BPMN segue um modelo de desenho livre, onde posso abrir diversos “braços” no desenho que, eventualmente, não serão sincronizados ou unidos ao final, serão simplesmente finalizados . Além disso, no BPMN tenho a liberdade de, estando em uma determinada atividade, ir para qualquer outra atividade, mesmo que seja uma anterior no desenho.
Já o BPEL possui um formato bloco-estruturado, onde todo o braço que é aberto precisa necessariamente ser fechado e onde não posso diretamente fazer coisas simples como representar a volta para um ponto passado do processo.
Assim, é conhecido que todo o processo em BPEL pode ser representado graficamente em BPMN, mas nem todo desenho BPMN pode ser representado em uma estrutura BPEL. Não diretamente.
No caso do nosso exemplo, acima veja como ele ficaria para se transformar em BPEL-compliance:
Sim, é isso mesmo, você não está vendo errado. Os dois fluxogramas representam o mesmo processo de negócio, a diferença é que este último foi adaptado para funcionar em uma ferramenta de execução em BPEL. Existem várias outras formas, entretanto, que poderíamos usar para representar esse mesmo processo para se ele ser compatível com BPEL.
Alguns ferramentas que usam BPMN e BPEL, para evitar ter que tratar com esse problema, simplesmente bloqueiam o desenho BPMN impedindo que o usuário monte processos que não sejam compatíveis. Veja o exemplo do desenho abaixo: quando tento criar uma conexão entre a última tarefa e a primeira tarefa, representando uma volta a um ponto passado do processo, o sistema me diz que “preciso colocar as tarefas dentro de um sub-processo em loop”, ou seja, devo utilizar um artifício de sub-processo para poder representar esse retorno. Chato não?
Assim, infelizmente, concluímos que muitos diagramas BPMN não são compatíveis com o modelo BPEL e tem que ser reescritos ou repensados antes de serem automatizados. Como fazer essa transformação? A primeira opção é transforma-se em um expert em BPMN e BPEL e gênio em lógica de processos para conseguir fazer essas adaptações. A segunda opção é verificar alguma das ferramentas de mercado que, de modo bastante discreto, dizem que conseguem fazer essa transformação diretamente . Os mais sérios inclusive divulgam: conseguimos converter automaticamente X% dos diagramas que você possui, os restantes Y% você terá que redesenhar. A terceira e última opção é avaliar muito bem os seus requisitos e verificar se você realmente precisa de BPEL.
De um modo ou de outro, a verdade que fica é que BPMN e BPEL foram criados por instituicões diferentes, grupos de empresas diferentes, em momentos diferentes. Então, essa integração que parece a primeira vista tão natural pode representar uma grande dor de cabeça se não for bem avaliada desde o início.
2 de Outubro de 2007 às 00:40
Rafael Bortolini
O BPMN (Business Process Modeling Notation) é uma notação e um conjunto de regras para modelagem e desenho de processos de negócio. Com o BPMN é possível
mapear em detalhes todos os processos de negócio da empresa, orientados ou não ao desenvolvimento de um software, e com a capacidade de representar relações entre empresas diferentes (clientes e fornecedores) , ao mesmo tempo com uma visão global da organização através do uso de sub-processos.
O BPMN foi criado e tem o apoio das principais empresas de TI do mundo, como IBM, SAP, Oracle e Microsoft. Atualmente, o BPMN é controlado pela OMG, mesmo organização internacional que controla o UML. Num futuro próximo, a tendência é que o UML (Diagramas de atividades) e BPMN irão se fundir.
O BPMN é independente de ferramenta, de sistemas ou de plataforma de operação. Praticamente todos os produtos de modelagem de processos do mundo já se adaptaram ou estão se adaptando ao modelo BPMN, incluindo Microsoft Visio, IDS Scheer Aris, Proforma Provision e IBM (http://www.bpmn.org/BPMN_Supporters.htm).
O principal objetivo do BPMN é diminuir a distância de entendimento entre os objetivos do projeto, definidos pelos sponsors, a análise de requisitos realizada por analistas e o programa desenvolvido pelos técnicos, reduzindo os riscos do projeto. Isso é possível através de uma notação simples porém poderosa e uma visão orientada a processos.
O BPMN, dentro da área de modelagem de processos, é a especificação que mais cresce e a única unanimidade, pois praticamente não possui concorrentes. O BPMN pode e deve ser utilizado como ferramenta no apoio ao desenvolvimento de softwares, e para empresas interessadas em controle de qualidade, certificação ISO ou CMM(i) ou melhoria de processos.
A utilização de um padrão permite que diferentes empresas e profissionais possam compartilhar conhecimentos e entendimentos sobre o funcionamento das regras de processos em comum.
22 de Agosto de 2007 às 12:14
Rafael Bortolini
Para quem está acompanhando nossa série de posts sobre padrões e siglas de BPM, finalmente o segundo capítulo. Acompanhe os anteriores aqui e aqui.
Existe muito material na Internet sobre o BPMN, pois trata-se do padrão mais difundido e utilizado atualmente dentro da área de BPM.
O BPMN foi desenvolvido inicialmente por uma organização composta basicamente por vendors e consultores de BPM, a BPMI (Business Process Management Initiative, http://www.bpmi.org), e foi lançado em maio de 2004. Logo, o BPMI foi incorporado à OMG (Object Management Group http://www.omg.org/) outra organização internacional que trata da especificação de uma série de padrões, entre eles o UML.
O BPMN com o tempo passou a receber apoio de diversas empresas de porte, como Microsoft, SAP, IBM e Oracle, o que com certeza ajudou na sua popularização. Ao contrário do XPDL, que analisamos antes, o BPMN é um padrão visual, isso é, ele é composto por uma série de objetos (desenhos) que são utilizados para mapear processos. Veja o exemplo abaixo de um diagrama BPMN:
Um dos objetivos do BPMN (muito nobre, pode-se dizer) é “aproximar a área de negócios e a área de TI”. Nesse sentido, o BPMN pode ser uma ferramenta eficaz de comunicação entre a área de negócios (que conheçe como funciona o fluxo de atividades) e a área de TI (que precisa automatizar esse fluxo), diminuindo os riscos de um projeto e tornando a solução final mais aderente aos objetivos de negócio. Isso significa, ao final, que tanto analistas quanto programadores deveriam ver um diagrama BPMN e entendê-lo da mesma maneira.
Quem já trabalhou com BPMN na prática, entretanto, sabe que nem tudo funciona assim. Em primeiro lugar, é muito fácil notar lendo a especificação que o BPMN foi feito por programadores, por pessoal técnico, e não por pessoal de negócio. Ou pelo menos foi feito mais por pessoal técnico. Além disso, o grande número de elementos que podem ser usados na modelagem de um processo pode tornar o fluxo confuso, e não é incomum encontrar um analista que usou ou tentou usar todos os elementos em um mesmo fluxograma, muitas vezes de maneira errada.
Por isso, a dica mais importante que fica é que, antes de começar a usar BPMN, é importante estudar a fundo a especificação e definir um set de elementos básicos, iniciais, que a empresa vai começar a trabalhar. Criar um manual de padronização interno, gerar alguns templates e comunicar a todos os analistas como a empresa irá usar o BPMN.
Mesmo com essas restrições, é inegável a importância do BPMN hoje. O jeito é contornar suas limitações e esperar a versão 2.0, que virá em 2008.
Enquanto isso, acompanhe um resumão do BPMN aqui .
26 de Julho de 2007 às 21:02
Rafael Bortolini
Publicações anteriores