What is the process mapping notation you use most and what you consider most appropriate?
With the advent of BPMN and integration in BPM suites I’ve seen a lot of discussion about the best standard for process mapping.
Vendors (except ARIS that supports EPC) have embed BPMN and BPEL for obvious reasons once it provides automatic process automation.
BPMN was presented as the process standard of the future because for the first time it could represent the participants in the processes, tasks, events and information flow. However, and contrary to process management methods that converged to the same concepts (Discovery, Analysis, Implementation, Monitoring and Improvement), the business process representation reached near chaos.
Companies that began their efforts in managing business processes in the last 10 years, used different trends, various notations and as result now is somewhat very mixed up. Process participants use process documentation or process representation pictured that tastes different. Some people understand task sequence and business rules that could cause bad process performance. Companies that began to structure business processes recently use the flavor of the year (EPC, Swimlane, etc.) and now don’t know what to do if is necessary to move to BPMN. On the other hand, when process improvement teams gather AS IS information sometimes they must rewrite or have to lose some time interpreting those dissimilar sketches (sounds familiar hum?).
Due to its complexity BPMN requires to qualify people to understand their contents. That is relearn how to draw and interpret processes (let's start all over again) some people will never make it. Lately, in various discussion forums I have noticed that still there is mapping and process improvement made on a brown paper with a marker and post-it glued with very good results, or using simple flow charts as before (this is typical in shopfloors process improvement workshops).
Half a year ago I completed an upgrade in an ERP system and used BPMN. The work was successful because people responsible for ERP implementation understood perfectly what changes were to be introduced (they were IT guys). When I tried to pass the changes to the people that were going to work with the system using the BPMN flows things stalled. I have convert everything to simple process flow notation.
There is a lot of debate about the adoption of BPMN and bearing in mind that version 2.0 is coming what is your opinion about the best notation for mapping business processes?
Vendors (except ARIS that supports EPC) have embed BPMN and BPEL for obvious reasons once it provides automatic process automation.
BPMN was presented as the process standard of the future because for the first time it could represent the participants in the processes, tasks, events and information flow. However, and contrary to process management methods that converged to the same concepts (Discovery, Analysis, Implementation, Monitoring and Improvement), the business process representation reached near chaos.
Companies that began their efforts in managing business processes in the last 10 years, used different trends, various notations and as result now is somewhat very mixed up. Process participants use process documentation or process representation pictured that tastes different. Some people understand task sequence and business rules that could cause bad process performance. Companies that began to structure business processes recently use the flavor of the year (EPC, Swimlane, etc.) and now don’t know what to do if is necessary to move to BPMN. On the other hand, when process improvement teams gather AS IS information sometimes they must rewrite or have to lose some time interpreting those dissimilar sketches (sounds familiar hum?).
Due to its complexity BPMN requires to qualify people to understand their contents. That is relearn how to draw and interpret processes (let's start all over again) some people will never make it. Lately, in various discussion forums I have noticed that still there is mapping and process improvement made on a brown paper with a marker and post-it glued with very good results, or using simple flow charts as before (this is typical in shopfloors process improvement workshops).
Half a year ago I completed an upgrade in an ERP system and used BPMN. The work was successful because people responsible for ERP implementation understood perfectly what changes were to be introduced (they were IT guys). When I tried to pass the changes to the people that were going to work with the system using the BPMN flows things stalled. I have convert everything to simple process flow notation.
There is a lot of debate about the adoption of BPMN and bearing in mind that version 2.0 is coming what is your opinion about the best notation for mapping business processes?
Comentários
I am sure all business people can understand BPMN in its very simplest form.
We have produced a Content Module to better present process information to users in Word using standard templates if you are interested - please see http://www.activemodeler.com/avantageContentManagement
Best regards
Geoffrey Long
glong@kaisha-tec.com
Na minha opinião, o BPMN tem como uma de suas principais vantagens a sua extrema facilidade de leitura. Costumo brincar com meus alunos e clientes dizendo que o BPMN nada mais é do que "um fluxograma metido a besta", o que, aliás, é exatamente o que ele é. A notação básica do BPMN (atividades como retângulos, decisões como losangos e círculos como eventos) é antiqüíssima (== fluxograma) e conhecida por virtualmente todo mundo. Em geral, não preciso de mais de 10 minutos para explicar a notação para novos "leitores", e eles sempre compreendem perfeitamente.
É claro que, para que isso seja possível, é necessário respeitar a curva de aprendizagem das pessoas. Não tem sentido despejar diagramas com a notação full logo de cara. O ideal é ir preenchendo as lacunas aos poucos. Eu começo com os itens básicos acima e mais uma pequena coleção de tipos de eventos (message e timer, normalmente) e os forks AND e OR e swimlanes / pools (esses últimos parecem ser incrivelmente intuitivos para todo mundo). Via Pareto, é fácil verificar que isso é capaz de representar mais de 80% das situações normais nas empresas. Conforme o tempo passa, é possível ir acrescentando mais sintaxe e semântica e cobrindo os casos mais complexos.
1) O fato de modelar processos em 'lanes' previamente estabelecidas funcionaliza a visão por processos, não permite que você enxergue o processo independentemente da organização do trabalho. Acho esse o 'defeito' mais grave, apesar de sutil. É um problema quase pedagógico.
2) Os message flows são uma boa sacada, mas aumentam a complexidade do modelo se forem exaustivos (e precisam ser), fazendo com que, por exemplo, o princípio da clareza seja violado e o modelo de processos perca uma parte importante da utilidade (a menos para o objetivo único de automação já citado).
3) O foco em automação induz o modelador a confundir fluxo de atividades com fluxo de informação. Um erro conceitual meio básico, mas muito comum.
4) A limitação de tipos de objetos e modelos para outras finalidades que não a automação (já mencionado neste fórum etc.) e relacionado às anteriores.
E outros. Enfim, é só minha opinião. Como docente (Eng. Produção / UFRJ), me obrigo a apresentar ambas para os alunos da diciplina de EPN, os faço praticar com EPC no laboratório, mas dou liberdade para usar qualquer notação em seus trabalhos de campo, muitos usam BPMN, EPC. Poucos IDEF e outras.
Sobre o aprendizado, tendo a concordar com os argumentos do artigo do Recker e Dreilling de 2007 (ref. a seguir), que concluem que não importa muito com que notação você aprende, no fim, você se habilita a aplicar todas, bastando vencer uma pequena curva de aprendizado acerca dos objetos e relações possíveis (além da operação da ferramenta, é claro). Acho que é por isso que o pessoal das 'réguas plásticas' (hein, Rui?) tem facilidade de modelar em qualquer notação.
Em ferramentas talvez a maior evolução tenha sido no acesso: por incrível que pareça tá mais barato.... tem até algumas boas ferramentas free e open-source.
Em termos de cultura, me permitam usar o termo... "involuímos".... e estamos tentando retomar o tempo dos Analistas de O&M (ei, Analista de Negócios, este título - Analista de Negócios - já é usado pela IBM desde os idos de 89/90... e é a mesma coisa de hoje... o sujeito que sabe mais de negócios mas que trabalha para TI ...). A re-engenharia foi confundida com redução de custos e o Analista de O&M (atual Analista de Processos) teve que virar Analista de Sistemas ou morreria de fome..
Quem estudava Administração de Empresas com ênfase em Análise de Sistemas (belo nome de curso.....) lembra que Cálculo, ADM, Economia e O&M eram mais importantes (difíceis) que Redes, Linguagem de Programação, Análise de Sistemas ou qualquer outra... e que outros cursos tinham as mesmas matérias (Engenharias, Economia, Administração, etc...). Hoje o imediatismo do mercado leva a uma formação meio "boba" em muitas instituições.... É incrível um graduado em qualquer meleca de TI não saber fazer um fluxograma, seja com as réguinhas verdes, com IDEF, com BPMN, sei lá mais o que. Eu não emprego ninguém (em qualquer área técnica) que esteja acima do terceiro ano que não saiba fazer um belo desenho de processo (de processo, não de sistema...). E, gente, este negócio de AS-IS, pelo amor de Deus, é muito raro ter algum valor.... a não ser que você esteja vendendo as horas para fazer o AS-IS... outro exemplo é em outra situação muito difícil de acontecer... você está fazendo uma comparação entre os processos da empresa compradora e a comprada para ver com qual fica....
Enfim, a melhor notação é a que a tua empresa usa.... se ainda não usa, pega a tendência do mercado.... na minha opinião, BPMN.